Unit tests Bombados

Oi,

Estou testando meus daos e actions utilizando o dbunit e hsqldb, o problema é que estou achando que os testes estão saindo muito "bombados" fazendo com que a simplicidade vá embora. Acho que estou fugindo um pouco do escopo de teste unitário ou talvez seja apenas paranóia de minha parte. Gostaria de opiniões sobre o teste abaixo.

[]'s

public class AuthorDaoTest extends DatabaseTestCase {
	
	private ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:applicationContext.xml");	
	
	private AuthorDao authorDao;

@Override
	protected DatabaseOperation getSetUpOperation() throws Exception {		
		authorDao = (AuthorDao) applicationContext.getBean("authorDao");		
		return DatabaseOperation.REFRESH;
	}

@Override
	protected DatabaseOperation getTearDownOperation() throws Exception {
		return DatabaseOperation.DELETE_ALL;
	}

protected IDatabaseConnection getConnection() throws Exception {    
    	       Connection connection = ((Session) applicationContext.getBean("session")).connection();
    	       connection.setAutoCommit(true);
               return new DatabaseConnection(connection);
        }

protected IDataSet getDataSet() throws Exception {
               return new FlatXmlDataSet(new FileInputStream("data/testData.xml"));
        }

public void testGetString() throws DaoException {
		assertNotNull(authorDao.get("admin"));
	}
   
        ....Outros testes

}

SetUp de uma action.

JavaGuru Membro desde: 03/11/2006 02:27:43 Mensagens: 206 Offline

bolado

Toda esta configuração dos testes pode estar numa classe intermediária que é extendida pelos seus testes. Desta maneira você evita duplicar esta configuração em todo TestCase e vai ajudar na questão da simplicidade

Quanto ao escopo dos testes de unidade, uma vez que o método que você está testando depende do banco de dados, ele já não está sendo testado isolado. No caso este virou um teste de integração.

Para testar o método isolado você teria que usar mocks para simular o comportamento do banco. O teste ficaria isolado, mas o comportamento real do banco não seria testado (você não conseguiria saber se um SQL iria ou não gerar erro, por exemplo).

Todo teste dbUnit por nao eh exatamente unitario (e sim de aceitacao, funcional ou, no minimo, de integracao). Entao, siga o conselho do Ivan e limpe a configuracao e setUp, mas nao esquente muito a cabeca com o que nao for problema

Oi,

Vou seguir a recomendação da classe intermediária para deixar o teste mais simples.

Quanto ao escopo, acho que para o meu caso vai ser mais útil um teste de integração em se tratando dos daos e nas actions utilizarei testes unitários com a utilização de mocks para simular o comportamento do banco.

Restou apenas uma dúvida quando a organização dos testes unitários e de integração.

<paranóia>
Geralmente vocês separam os testes de unitários dos de integração? Ou eles ficam no mesmo source folder?
</paranóia>

[]´s

Um critério para deixar junto ou separado é desempenho. Uma boa prática é manter os testes rodem sempre o mais rápido possível.

Ou seja, se os testes de integração começarem a levar muito mais tempo que os outros para rodar, daí é o caso em se pensar em pelo menos criar um TestSuite específico para eles.

Até lá não vejo porque se preocupar com essa questão. Afinal, o objetivo de testar já está sendo alcançado

Notícias, artigos e o maior fórum brasileiro sobre Java