Cobertura de código com testes unitários como métrica de qualidade

JavaGuru Membro desde: 26/10/2006 16:30:23 Mensagens: 220 Offline

Saudações gujeiros,

O que vocês acham de utilizar como métrica de qualidade, os índices de cobertura do código com testes unitários.

Na minha opinião, a porcentagem gerada pelo cobertura é um número muito falho.

Na empresa onde trabalho estão discutindo a possibilidade de falhar a build caso um determinado índice de cobertura não seja atingido. Ao meu ver, isso vai causar alguns problemas, pois somente para atingir a meta, vai ter teste unitário pra coisas inúteis como por exemplo get/set/EntityManager.Persist etc.
Pode acontecer também de ter sistemas com vários testes inúteis, e o CORE das regras de negócio estarem mal testados, porém o projeto como um todo ficar com uma boa taxa de cobertura.

Atualmente utilizamos o "Cobertura" com o maven, porém as configurações dele não são muito boas. Possuímos apenas configuração de patterns de nomes de classes que não desejamos testar.

Existe alguma outra ferramenta de cobertura que possa ser ter uma configuração melhor como por exemplo patterns para os nomes dos métodos que serão testados, quantidades de linhas do método etc?

Obrigado
[]s

Impor um limite minimo para cobertura durante o build eh besteira. Primeiro porque este numero nao comprova qualidade dos testes. Segundo porque forca os programadores a escreverem testes sem questionar sua necessidade.

Minha sugestao eh: faca essa metrica visivel e discuta estes valores periodicamente. A equipe pode aprender licoes importantes conversando sobre cobertura de testes, sem que para isso precisem conviver com uma nova restricao.

Números são uma droga. Já vi empresas onde os funcionários se matam pra atingir
índices de tarefas feitas, sem nenhuma preocupação com a qualidade.

JavaGuru Membro desde: 26/10/2006 16:30:23 Mensagens: 220 Offline

Pois é, eu tenho a mesma opinião de vocês.

Agora, já que temos que comparar números, gostaria de conseguir ajustar melhor o que entra nesse número. Um amigo comentou uma vez de um patch pro cobertura que analisava o bytecode gerado e se fosse um método "trivial", ele não era considerado pelo plugin. Os métodos triviais eram métodos acessores onde soh havia atribuição / leitura de objetos. Vocês usam alguma coisa assim?

Obrigado
[]s

Acho que esse número de cobertura é uma consequência. O objetivo é fazer o software.
Se fizer direito vai ter uma cobertura boa de teste e isso não é necessariamente 100%.
Uma vez o s4nchez colocou num post aqui um link, de uma métrica boa para acompanhar
http://xprogramming.com/xpmag/jatRtsMetric

Isso sim vale a pena acompanhar.

Exigir percentual mínimo de cobertura pode ser reflexo do mau entendimento de para que servem os testes. Não acho que faça sentido 100% de cobertura. Eu acredito mais em testar o comportamento do seu software. Se testando bem o comportamento você atingir 100% de cobertura, muito bem. Se não, que diferença isso faz?

[]s

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 517 Offline

Eu acho que isso pode ter o efeito contrario ao que se espera.

Escrevendo testes inuteis os programadores vao se encher dos testes e parar de escrever tambem os uteis. No final das contas vao notar que essa abordagem nao funcionam e ainda de quebra criarao aversao a teste unitario nos programadores.

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