Estamos iniciando um impulso para a cobertura de código aqui no meu trabalho, e isso me levou a pensar .... Quanta cobertura de código é suficiente?

Quando você chega ao ponto de diminuir os retornos na cobertura do código? Qual é o ponto ideal entre uma boa cobertura e não o suficiente? Isso varia de acordo com o tipo de projeto que você está realizando (por exemplo, WPF, WCF, Mobile, ASP.NET) (essas são as classes C # que estamos escrevendo).

Nosso objetivo é pelo menos 70%. Em coisas que são mais facilmente testáveis ​​(estruturas de dados funcionais, por exemplo), almejamos 90% e a maioria dos indivíduos almeja o mais próximo possível de 100%. Em coisas relacionadas ao WPF e outras estruturas que são muito difíceis de testar, obtemos uma cobertura muito menor (quase 70%).

Sou da opinião de que a cobertura do código por si só é uma métrica ruim. É fácil produzir toneladas de testes inúteis que cobrem o código, mas não verificam adequadamente a saída ou não testam casos extremos, por exemplo. Cobrir o código significa apenas que não gera uma exceção, não que esteja certo. Você precisa de testes de qualidade - a quantidade não é tão importante.

"Chega" é quando você pode fazer alterações no seu código com confiança de que não está quebrando nada. Em alguns projetos, isso pode ser de 10%, em outros, pode ser de 95%.

Quase nunca é tão alto quanto 100%. No entanto, às vezes, tentar obter 100% de cobertura do código pode ser uma ótima maneira de remover cruft da base de código. Não se esqueça de que há duas maneiras de aumentar a cobertura do código - escreva mais testes ou retire o código. Se o código não for coberto por ser difícil de testar, há uma boa chance de você simplificar ou refatorar para facilitar o teste. Se é muito obscuro para se preocupar em testar, geralmente há uma boa chance de que nada mais esteja no código.

A cobertura do código se aproxima de 100% assintoticamente. Consequentemente, esses últimos 5% provavelmente são mais esforços do que valem, à medida que você começa a obter retornos muito pequenos para o esforço despendido.

A cobertura é uma métrica para ficar de olho, mas não deve ser o objetivo final. Eu já vi (e admito que escrevi!) Bastante código de alta cobertura - 100% de cobertura (TDD, é claro), ainda:

• erros ainda surgem
• o design ainda pode ser ruim
• você pode realmente se matar atirando em algum alvo arbitrário de cobertura - escolha suas batalhas: p

Há um "The Way of Testivus" entrada que eu acho que é apropriado para fazer referência aqui :)

Apenas 20% da maioria dos códigos executam 80% do tempo . Uma análise de cobertura de código não é muito útil, a menos que seja combinada com um gráfico de chamada para determinar o que precisa ser mais testado. Isso indica onde é provável que seus casos extremos estejam. Você pode criar 100 testes apenas para os casos extremos, que constituem menos de 5% do código real.

Portanto, certifique-se de cobrir 100% dos 20% que definem caminhos críticos e pelo menos 50% do restante (de acordo com o gráfico de chamadas). Isso deve dar a você (aproximadamente) 70% - 75% de cobertura total, mas isso varia.

Não gaste tempo tentando obter mais de 70% de cobertura total, deixando casos críticos sem verificações.

Use a cobertura como um guia para indicar áreas não testadas. Em vez de ter um mandato de cobertura, é mais prudente entender o motivo do código não coberto. Registrar uma razão para o déficit é uma boa disciplina que permite que os riscos sejam equilibrados.

Às vezes, o motivo é menos do que desejável ', por exemplo, o tempo esgotou', mas pode ser bom para uma versão inicial. É melhor sinalizar áreas para retornar mais tarde para aumentar a cobertura.

Trabalho em software de voo crítico, onde 100% de cobertura de declaração é considerada adequada para sistemas não críticos. Para os sistemas mais críticos, verificamos a cobertura da filial / decisão e usamos uma chamada técnica MC / DC que às vezes não é rigorosa o suficiente.

Também precisamos garantir que também cobrimos o código do objeto.

É um equilíbrio entre risco, no nosso caso, muito alto e valor / custo. É necessária uma escolha informada com base no risco de falta de um bug.

Quando você começa a considerar as mudanças que afetariam o desempenho, a segurança, a flexibilidade ou a manutenção do tempo de execução para permitir mais cobertura de código, é hora de encerrar a busca por mais cobertura de código.

Tenho projetos em que esse ponto é 0% porque é impossível calcular a cobertura sem prejudicar o design e outros projetos em que chega a 92%.

As métricas de cobertura de código são úteis apenas para indicar onde você pode ter perdido alguns testes. Eles não dizem nada sobre a qualidade dos seus testes.

O software de espaço crítico requer 100% de cobertura de declaração.

No começo, não faz sentido. Todo mundo sabe que uma cobertura de teste completa não significa que o código foi totalmente testado e que não é tão difícil obter 100% de cobertura sem realmente testar o aplicativo.

No entanto, 100% de cobertura é um limite inferior: embora 100% de cobertura não seja uma prova de um software livre de erros, é certo que, com uma cobertura menor, o código não é totalmente testado e isso é simplesmente inaceitável para softwares críticos para o espaço.

Eu realmente gosto da resposta do @ RevBingo, porque ele sugere que a luta em direção a 100% pode fazer com que você limpe ou exclua o código não utilizado. O que não vi nas outras respostas é uma sensação de quando você precisa de alta cobertura e quando não. Eu tomei uma facada em começar isso. Acho que adicionar detalhes a um gráfico como esse seria uma busca mais útil do que encontrar um número de cobertura de teste adequado para todo o código.

100%

Para uma API pública, como as coleções java.util, que não é acoplada a um banco de dados e não retorna HTML, acho que 100% de cobertura é uma meta inicial nobre, mesmo se você se contentar com 90-95% devido a tempo ou outro restrições. Aumentar a cobertura do teste após a conclusão do recurso força um nível de análise mais detalhado do que outros tipos de revisão de código. Se a sua API for popular, as pessoas a usarão, subclassificarão, desserializarão etc. de maneiras que você não pode esperar. Você não quer que a primeira experiência deles seja encontrar um bug ou supervisionar o design!

90%

Para o código de infraestrutura de negócios, que absorve estruturas de dados e retorna estruturas de dados, 100% ainda é provavelmente uma boa meta inicial, mas se esse código não for público o suficiente para convidar muito uso indevido, talvez 85% ainda seja aceitável?

75%

Para o código que recebe e retorna Strings, acho que o teste de unidade é muito mais frágil, mas ainda pode ser útil em muitas situações.

50% ou menos

Eu odeio escrever testes para funções que retornam HTML porque é muito quebradiço. E se alguém alterar o CSS, o JavaScript ou todo o blob de HTML e inglês que você retornar não fizer sentido para os usuários finais humanos? Se você puder encontrar uma função que use muita lógica de negócios para produzir um pouco de HTML, vale a pena testar. Mas a situação inversa pode não valer a pena testar.

Perto de 0%

Para alguns códigos, a definição de "correto" é "faz sentido para o usuário final". Existem testes não tradicionais que você pode executar com relação a esse código, como verificação gramatical automatizada ou validação HTML da saída. Eu até configurei declarações grep para pequenas inconsistências às quais geralmente somos vítimas no trabalho, como dizer "Login" quando o resto do sistema chama "Login". Esse homem não é estritamente um teste de unidade, mas uma maneira útil de capturar problemas sem esperar resultados específicos.

Em última análise, porém, apenas um humano pode julgar o que é sensível aos humanos. O teste de unidade não pode ajudá-lo lá. Às vezes, são necessários vários humanos para julgar isso com precisão.

Absoluto 0%

Esta é uma categoria triste e eu me sinto menos uma pessoa por escrevê-la. Porém, em qualquer projeto suficientemente grande, existem tocas de coelho que podem sugar semanas de pessoas por pessoa, sem fornecer nenhum benefício comercial.

Comprei um livro porque alegava mostrar como simular dados automaticamente para testar o Hibernate. Mas ele apenas testou as consultas Hibernate HQL e SQL. Se você precisa fazer muito HQL e SQL, realmente não está obtendo a vantagem do Hibernate. Existe uma forma de banco de dados na memória do Hibernate, mas não investi tempo para descobrir como usá-lo efetivamente nos testes. Se eu tivesse essa execução, gostaria de ter uma cobertura de teste alta (50% -100%) para qualquer lógica comercial que calcule coisas navegando em um gráfico de objeto, fazendo com que o Hibernate execute algumas consultas. Minha capacidade de testar esse código está perto de 0% no momento e isso é um problema. Portanto, aprimoro a cobertura de teste em outras áreas do projeto e tento preferir funções puras sobre aquelas que acessam o banco de dados, principalmente porque é mais fácil escrever testes para essas funções. Ainda,

Eu acho que depende da parte do aplicativo que você está testando. Por exemplo, para lógica de negócios ou qualquer componente que envolva transformações complexas de dados, eu visaria uma cobertura de 90% (o mais alto possível). Eu sempre encontrei erros pequenos, mas perigosos, testando o máximo possível do código. Prefiro encontrar esses bugs durante o teste do que deixá-los ocorrer no site do cliente um ano depois. Além disso, um benefício de uma cobertura de código alta é que ela impede que as pessoas alterem o código de trabalho com muita facilidade, pois os testes precisam ser adaptados de forma correspondente.

Por outro lado, acho que existem componentes para os quais a cobertura do código é menos adequada. Por exemplo, ao testar uma GUI, é muito demorado escrever um teste que cubra todo o código executado ao clicar em um botão para despachar o evento para os componentes certos. Eu acho que, neste caso, é muito mais eficaz usar a abordagem tradicional de executar um teste manual no qual você apenas clica no botão e observa o comportamento do programa (a janela de diálogo correta se abre? A ferramenta correta é selecionada ?).

Não tenho uma opinião tão alta sobre o uso da cobertura de código como uma medida para saber quando seu conjunto de testes tem cobertura suficiente.

A principal razão disso é que, se você tem um processo em que primeiro escreve algum código, depois faz alguns testes e depois analisa a cobertura do código para descobrir onde perdeu um teste, é o processo que precisa melhorar. Se você faz TDD verdadeiro, possui uma cobertura de código 100% pronta para uso (é certo que existem algumas trivialidades que não testo). Mas se você olhar a cobertura do código para descobrir o que testar, provavelmente escreverá os testes errados.

Portanto, a única coisa que você pode concluir da cobertura do código é que, se for muito baixo, você não terá testes suficientes. Mas se for alto, não há garantia de que você tenha todos os testes certos.