Dúvidas sobre TDD e MVC

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

http://www.carbonfive.com/community/

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.

s4nchez:

Andre Brito:

1 - Quando eu sei que não preciso de mais testes unitários?

Como o Kent Beck cita no livro dele, você possuirá testes o suficiente “quando o medo se transformar em tédio”.

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.
É 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:

http://java-source.net/open-source/code-coverage

psevestre:

Andre Brito:

1 - Quando eu sei que não preciso de mais testes unitários?

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

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.