| Autor |
Mensagem |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 19/09/2010 21:06:12
|
rmendes08
GUJ Master
![[Avatar]](/images/avatar/9ee855f3ce4dd40182183463232e2162.jpg)
Membro desde: 29/05/2008 14:09:28
Mensagens: 1617
Online
|
Bem , perguntando aos que tem mais experiência com testes automatizados e TDD, a minha dúvida é a seguinte: dadas as restrições de custo e tempo de um projeto não dá pra escrever testes para absolutamente TODAS as classes do meu sistema. Assim, devemos obter a maior cobertura de testes possível com o menor número destes. Fica então a minha pergunta, qual deve ser a minha prioridade na hora de escrever testes automatizados ? Qual a cobertura de código que eu posso considerar satisfatória ? 80% , 90% ?
|
"A Técnica é transformada em Arte por quem a emprega"
"O futuro pertence àqueles que acreditam na beleza de seus sonhos"
Computadores Fazem Arte
http://www.uaijug.com.br
"É importante estabelecer uma estrutura de alto nível, mas isso não significa criar uma infinidade de diagramas de classes detalhados." |
|
|
 |
|
|
![[Post New]](/templates/default/images/icon_minipost_new.gif) 20/09/2010 08:59:52
|
luizSC
JavaBaby
Membro desde: 29/07/2010 19:10:45
Mensagens: 76
Offline
|
Não há um percentual aceitável ou não aceitável.
Basicamente, a quantidade de testes faltante é proporcional à aflição que o software lhe causa . Principalmente na liberação de novas releases. Ou seja, quando você é capaz de liberar uma nova versão de um sistema em produção sem perder o sono, sua cobertura de testes tende a estar satisfatória.
Para as classes e métodos novos, escreva uma classe de testes antes de começar a implementação. Isso aumenta as suas chances de entrar num cíclo que manterá a nova classe sempre em dia com os testes.
|
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 22/09/2010 02:36:31
|
cv
Moderador
![[Avatar]](/images/avatar/210f760a89db30aa72ca258a3483cc7f.jpg)
Membro desde: 04/04/2003 00:32:12
Mensagens: 7842
Localização: São Paulo, SP
Offline
|
Nao pense em testar uma classe: teste uma funcionalidade, quaisquer sejam as classes necessarias para que a funcionalidade exista sem bugs.
Deixa de ser unit testing, mas ajuda *bastante*.
|
|
|
 |
|
|