Técnicas para realizar testes unitários

Olá,

pessoal como vocês realizam os testes unitários de operações CRUD ? Alguém tem alguma referência que fale sobre isso ? Ou alguém pode relatar como é feito ?

Por exemplo, como vocês manipulam a base de dados ? Diretamente na mão ou via teste também, exemplo: na operação de consulta, devo no mesmo teste incluir os registros e depois buscá-lo ? Como vocês criam as classes de Teste ? Uma para cada entidade ? Por exemplo a entidade Cliente, vocês colocam todos os testes referentes a clientes nessa classe ?

Valeu!

use dbunit p/ controlar os registros que vc vai usar nos seus testes.

http://dbunit.sourceforge.net/

[]'s

Quanto faço testes unitários de métodos que envolvem persistencia eu uso mocks pros objetos relativos a persistencia como DAOs, Hibernate Session, etc.

Um teste que acessa o banco de dados não é unitario.

Um teste que acessa o banco de dados não é unitario.

Com o DBUnit seu teste vai acessar o banco de dados para ajudar nos asserts

Fabrício Cozer Martins wrote:
Pessoal como vocês realizam os testes unitários de operações CRUD ? Alguém tem alguma referência que fale sobre isso?
Ou alguém pode relatar como é feito?

Para testar uma inserção insiro o objeto, pego o id faço uma busca e verifico se inseriu.

Para fazer uma consulta simples insiro uma ou mais objetos dependentes, sei os valores inseridos, preencho o filtro e verifico se foram retornados x objetos em uma consulta. A parte de carga pode ser feita pelo DBUnit mas não vejo muito ganho, nesse caso prefiro java a xml.

Os testes não são realmente unitário mas para testar isso tem que ser em métodos diferentes mesmo...

Fabrício Cozer Martins wrote:
Por exemplo, como vocês manipulam a base de dados?
Diretamente na mão ou via teste também, exemplo: na operação de consulta, devo no mesmo teste incluir os registros e depois buscá-lo?

Manipulo a base toda no testes inserindo e busco tudo nos testes.

É tudo transacional e posso rodar os testes sempre...
Você pode escolher usar o DBUnit também. Você dá uma carga no banco usando XML e pode contar com esses dados durante os testes unitários.
É uma questão de escolha.

Fabrício Cozer Martins wrote:
Como vocês criam as classes de Teste?
Uma para cada entidade?
Por exemplo a entidade Cliente, vocês colocam todos os testes referentes a clientes nessa classe?

Uso uma classe que herda de AbstractTransactionalDataSourceSpringContextTests do Spring em meus testes de DAO.

Usar reflexão para inserir valores no objeto que está sendo testado facilita muito o teste.

Os relacionamentos de um objeto com outras tabelas devem ser setados "na mão" mas só de preencher todas as propriedades obrigatórias e testar inserção em todas as colunas já ajuda.

Para testar classes com regras de negócio uso o EasyMock e não acesso o banco.

Uma técnica que eu já vi sugerida mas nunca usei é rodar um banco em memória para fazer os testes. (eu costumo mockar o acesso a recursos).

AllMighty wrote:Uma técnica que eu já vi sugerida mas nunca usei é rodar um banco em memória para fazer os testes. (eu costumo mockar o acesso a recursos).

Quando usar um banco eh absolutamente e estritamente necessario (ou seja, vc ta testando a camada mais funda do sistema, nao uma regra de negocios qualquer), usar um banco em memoria (HSQL eh o que a gente usa direto aqui) vai bem.

Mas so deve ser usado numa parte da aplicacao que normalmente acaba sendo testada por testes funcionais, anyway... faz sentido ter certeza que a configuracao do Hibernate ta certa num teste unitario?

cv wrote: faz sentido ter certeza que a configuracao do Hibernate ta certa num teste unitario?

Eu acho importante, principalmente porque você consegue pegar aqueles erros chatos de colunas com nomes errados e esse tipo de coisa.

Ok, mas se vc ta falando com o banco, nao ta na hora de ter uma suite de testes funcionais, mesmo que sejam so smoke tests?

cv wrote:Ok, mas se vc ta falando com o banco, nao ta na hora de ter uma suite de testes funcionais, mesmo que sejam so smoke tests?

Com certeza

Hum, testes que usam banco não são unitários? Os testes que eu faço nos EJBs com o DBUnit para ver se os finders estão fazendo as buscas corretamente ou se os métodos de negócio estão certo não são unitários?

microfilo wrote:Hum, testes que usam banco não são unitários? Os testes que eu faço nos EJBs com o DBUnit para ver se os finders estão fazendo as buscas corretamente ou se os métodos de negócio estão certo não são unitários?

Não, por que o resultado de teste unitário deve depender exclusivamente da unidade que está sendo testada e ele deve ser robusto e consistente: sempre fornecer o mesmo resultado para a mesma implementação de uma classe. Ficaria muito difícil confiar em testes que dizem uma coisa hoje e amanhã dizem outra diferente, e usar banco de dados em testes unitários leva a isso.

Sim, é justamente esse ponto, o teste unitário não deve 'atrapalhar' outros testes, é isso que quero entender como fazer na melhor maneira possível, porque antes de executar os testes unitários , a base de dados deve estar num formato X, e depois de executar os testes o banco deve retornar ao estado X, ou não ?

Como vocês fazem? Deixam uma instância do banco pra cada desenvolvedor ?
O HSQL não pode esconder alguns erros ? Pois se como eu uso outro banco .. ficaria complicado testar no HSQL.
Vou dar uma olhada no dbunit.
Outra coisa também quando vocês na mesma suite de testes, testam inclusões, vocÊs no mesmo teste, obtém para verificar se foi incluída corretamente, e depois do método de teste vcs excluem os registros incluídos ? É que aí estaria testando os métodos de inclusão, consulta, e exclusão...

microfilo wrote:Hum, testes que usam banco não são unitários?

Nope. Podem ser testes funcionais ou de integracao, mas por definicao nao podem ser unitarios. Testes unitarios testam uma unidade de cada vez - se vc ta usando um banco de dados, quer dizer que tem mais de uma classe envolvida (nem que seja uma Connection jdbc).

microfilo wrote:Os testes que eu faço nos EJBs com o DBUnit para ver se os finders estão fazendo as buscas corretamente ou se os métodos de negócio estão certo não são unitários?

Nope. Unitarios so testam uma classe.

cv wrote:
Nope. Unitarios so testam uma classe.

Você está dizendo que se estou testando um método de uma classe e este por sua vez invoca outras classes, o teste não é mais unitário?

Pelo que eu sei, testes de unidade servem pra "exercitar" uma pequena porção de código (normalmente um método isolado), independente do que esta porção faz.

Se eu entendi errado (sua afirmação ou o conceito) por favor me corrija

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