Pessoal,
Do nada me veio à cabeça duas perguntas:
1 - Quando eu sei que não preciso de mais testes unitários?
2 - Como fazer TDD com consultas ao banco (que é um mock)? Usando Hash ou alguma coisa parecida?
Abraço.
você tem que analisar o aspecto funcional e não-funcional, se você pensar assim, você sempre achará mais uma coisa a testar e verificar
procure focar nos requisitos funcionais, que é o que mais importa para o cliente, e posteriormente limites da sua arquitetura de projeto, através de testes planejados e preventivos
não subestime requisitos nao-funcionais, como acaba sendo desbanjado pelos gerentes, pois se você diz ao cliente que sua arquitetura de projeto suporta 1 mil usuarios silmutaneos com tempo de resposta de ate 10 segundos, como fica se não o fizer?
geralmente o que se faz é identificar o grau de cobertura de precaveniência do código escrito, bem como a partir de lógicas cobertas no código, como por exemplo análise de pairwise, tabelas de decisao, entre outras técnicas, identificados durante a antecipação da programação
você também poderá identificar gargalos que devem ser sinalizados quando ocorrerem em uma mudança eventual, ou seja, problemas de recorrência de testes, que é bastante desgastante em ambiente de fábrica de software
Como o Kent Beck cita no livro dele, você possuirá testes o suficiente “quando o medo se transformar em tédio”.
Para testes envolvendo banco de dados geralmente se usa um banco em memória (e.g. sqlite, hsqldb, etc) e Carrega-se Fixtures antes de cada teste limpando ao final.
[quote=s4nchez][quote=Andre Brito]
1 - Quando eu sei que não preciso de mais testes unitários?
[/quote]
Como o Kent Beck cita no livro dele, você possuirá testes o suficiente “quando o medo se transformar em tédio”.[/quote]
Testes unitários são super valorizados. Tem gente que acha que deve usar em todo projeto e em toda parte do projeto. Engraçado que o próprio Kent Beck recentemente disse que testes são dispensáveis em muitos projetos.
Emerson,
Essa de carregar Fixtures antes é pra não mexer no banco enquanto faço os testes, né?
Valeu Ivan, Rafael, Emerson e Moch.
Emerson,
Essa de carregar Fixtures antes é pra não mexer no banco enquanto faço os testes, né?
Valeu Ivan, Rafael, Emerson e Moch.[/quote]
É para ter um estado consistente no início e ao final dos seus testes.
Uma forma é medir quanto do seu código é “exercitado” pelos testes unitários. Se vc. for por este caminho é fundamental medir a cobertura dos testes. Felizemente há uma boa oferta de ferramentas para isto:
[quote=psevestre][quote=Andre Brito]
1 - Quando eu sei que não preciso de mais testes unitários?
[/quote]
Uma forma é medir quanto do seu código é “exercitado” pelos testes unitários. Se vc. for por este caminho é fundamental medir a cobertura dos testes. Felizemente há uma boa oferta de ferramentas para isto:
http://java-source.net/open-source/code-coverage
[/quote]
Oi psevestre.
Valeu pela dica cara.
Lendo rapidamente a descrição do Cobertura, eu tive uma impressão errada (eu espero): ele mede a porcentagem que os testes são executados. É isso?
Me parece meio estranho isso… Porque pensa bem, se eu tenho uns testes unitários que testam poucas coisas que acontecem, mas frequentemente, eu tenho uns testes unitários que são bastante executados. Ou seja, a porcentagem deles vai ser alta. Mas isso não indica que eu testei eventos que podem ser que aconteçam e eu não consiga ver.
Posso ter falado com sem nexo, mas a priori me parece ser um tanto quanto válido.
Não. Leia de novo o que está escrito lá:
Traduzindo: Cobertura é uma ferramenta Java gratuita que calcula a porcentagem do código “acessada” (tradução aproximada) por testes.
Exemplificando: se seu código tem 1000 linhas e o conjunto de testes “passa” por 200, a cobertura é de 20%. Na ferramenta vc. pode navegar pelos resultados e verificar quais trechos de código foram executados ou não ao longo da bateria de testes unitários.