Unit tests Bombados

Programação Arquitetura
#1

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.

protected DatabaseOperation getSetUpOperation() throws Exception {

        action = (AuthorAction) applicationContext.getBean("authorAction");		
		
	action.getAuthor().setLogin("admin");
	action.getAuthor().setPassword("123456");
		
	ActionContext.getContext().setSession(new HashMap());
		
	return DatabaseOperation.REFRESH;
}
#2

bolado

#3

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).

#4

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 :wink:

#5

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

#6

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 :wink:

#7