Cobertura de 100% é uma meta ambiciosa de um mundo feliz onde não nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real não é vendável, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padrão aceitável.”

Não acho que seja tão utópico assim. A turma da ImproveIt por exemplo trabalha com 100% de cobertura. Aqui na Fortes, todo código novo deve ser produzido com 100% cobertura. Há casos que é realmente chato, como os Sets e Gets simples, mas aqui por exemplo se resolveu por reflexão (no caso de Java), fazendo a cobertura de forma automatizada. Já ouvi falar de ferramentas que fazem isso.

Nossos servidores de integração não permitem redução da taxa de cobertura. Se cair, a “build” quebra. Ou seja, o destino é 100%. E por que ainda não é 100%? Infelizmente temos um legado muito grande. Mas um dia chegamos lá.

Achei interessante a discussão proposta e coloquei uma referência em meu blog apontando para o seu post e o do Clavius Tales. Segue o endereço.

http://brunotg.wordpress.com/

Abraços
Bruno Guimarães

Sobre até quanto testar eu também não sei responder. Mas acho que os testes tem sua grande importância durante o desenvolvimento e deveriam ser levados mais a sérios por todos os membros da equipe.

Excelente post, fico no aguardo das tuas conclusões.

100% é algo meio impossível, principalmente quando envolve regras mais complexas com comunicações Webservices, integração com outros sistemas e cálculos matemáticos mais profundos. Mas concordo contigo que é algo que deve ser buscado sempre.

Ultimamente venho falando sobre a importância de se testar a exaustão, garantir o máximo de qualidade do que foi desenvolvido. Falo com frequência aos membros da equipe, principalmente para as pessoas que estão iniciando a desenvolver. E algo que estou notando é a dificuldade que as pessoas encontram em testar.

E por experiência própria, sei que criar um teste consistente exige mais que desenvolver. Principalmente quando os testes são para os cenários que eu citei acima. Criar mocks, criar cenários, fazer cargas iniciais para testes de módulos dependentes são as grandes barreiras. Como exigem que o profissional pense, vejo a preguiça reinar em muitos casos e os testes manuais voltam a entrar em cena. Quando me deparo com situações como estas, estou buscando fazer testes das minhas atividades mostrando a todos os benefícios para incentivá-los a criar testes também.