Cobertura de código é uma métrica enganosa se 100% cobertura é o seu objetivo (em vez de 100% teste de todas as características).

Podes ganhar 100% se acertares em todas as linhas uma vez. No entanto, você ainda pode perder o teste de uma determinada sequência (caminho lógico) em que essas linhas são atingidas.
• Você não conseguiu um 100%, mas ainda assim testou todos os seus 80%/freq usado código-caminhos. Ter testes que testam todos os "throw ExceptionTypeX" ou guarda de programação defensiva semelhante que você colocou é um "bom ter" não um "deve ter"

A cobertura do Código é óptima, mas a cobertura da funcionalidade é ainda melhor. Não acredito em cobrir todas as linhas que escrevo. Mas eu acredito em escrever 100% Cobertura de teste de toda a funcionalidade que eu quero fornecer (mesmo para as características extra legal que eu vim comigo e que não foram discutidos durante as reuniões).

A resposta aceite faz um bom ponto - não há um único número que faça sentido como um padrão para cada projecto. Há projetos que simplesmente não precisam de tal padrão. Quando a resposta aceite fica aquém, em minha opinião, é descrever como se pode tomar essa decisão para um determinado projecto.

Quando definir a cobertura do Código requisitos

A cobertura do Código é uma medição objetiva: uma vez que você veja o seu relatório de cobertura, não há ambiguidade sobre se as normas foram cumpridas são úteis. Prova a correcção? De modo algum, mas tem uma relação clara com o quão bem testado o código é, o que, por sua vez, é a nossa melhor maneira de aumentar a confiança na sua correcção. Code code coverage é uma aproximação mensurável de imensurável qualidades que nos interessam.

Alguns casos específicos em que uma norma empírica pode acrescentar valor:

• satisfazer as partes interessadas. para muitos projectos, existem vários actores que têm interesse na qualidade do software que podem não estar envolvidos no desenvolvimento quotidiano do software (gestores, pistas técnicas, etc.) Dizer "nós vamos escrever todos os testes que realmente precisamos" não é convincente: eles ou precisam confiar inteiramente, ou verificar com o fechamento contínuo supervisão (assumindo que têm o entendimento técnico para o fazer.) Fornecer padrões mensuráveis e explicar como eles razoavelmente aproximar os objetivos reais é melhor.
• Para normalizar o comportamento da equipa.Para além das partes interessadas, se estiver a trabalhar numa equipa onde várias pessoas estão a escrever códigos e testes, há margem para ambiguidades para o que se qualifica como "bem testado"."Será que todos os seus colegas têm a mesma ideia de que nível de teste é bom o suficiente? Provavelmente não. Comer reconciliaste isto? Encontre uma métrica em que todos possam concordar e aceitá-la como uma aproximação razoável. Isto é especialmente (mas não exclusivamente) útil em grandes equipes, onde as pistas podem não ter supervisão direta sobre Desenvolvedores Júnior, por exemplo. Redes de confiança também importam, mas sem medidas objetivas, é fácil para o comportamento de grupo se tornar inconsistente, mesmo que todos estejam agindo de boa fé.
• Para te manteres honesto.Mesmo que sejas o único desenvolvedor e apenas stakeholder para o seu projeto, você pode ter certas qualidades em mente para o software. Em vez de fazer avaliações subjetivas sobre o quão bem testado o software é (o que requer trabalho), você pode usar a cobertura de código como uma aproximação razoável, e deixar as máquinas medi-lo para você.

Quais as métricas a utilizar

A cobertura do código não é uma única métrica; existem várias maneiras diferentes de medir a cobertura. Qual deles você pode definir um padrão depende do que estás a usar esse padrão para satisfazer.

Usarei duas métricas comuns como exemplos de quando poderá usá-las para estabelecer padrões:

• cobertura da Declaração: que percentagem de declarações foram executadas durante os testes? Útil para ter uma noção da cobertura física do seu código: quanto do código que escrevi eu realmente testei?
  • Este tipo de cobertura suporta um argumento de correcção mais fraco, mas também é mais fácil de conseguir. Se você está apenas usando a cobertura de código para garantir que as coisas são testadas (e não como um indicador de qualidade de teste além disso) então a cobertura de declaração é provavelmente suficiente.
• cobertura do ramo : quando existe uma lógica de ramificação (por exemplo, um if), ambos os ramos foram avaliados? Isto dá um melhor sentido da cobertura lógica do seu código: quantos dos possíveis caminhos que o meu código pode percorrer já testei?
  Este tipo de cobertura é ... um indicador muito melhor de que um programa foi testado através de um conjunto abrangente de entradas. Se você está usando a cobertura de código como sua melhor aproximação empírica para a confiança na correção, você deve definir padrões baseados na cobertura de branch ou similar.

Existem muitas outras métricas (a cobertura das linhas é semelhante à cobertura das declarações, mas produz diferentes resultados numéricos para as declarações multi-linhas, por exemplo; a cobertura condicional e a cobertura do canal é semelhante à cobertura do ramo cobertura, mas refletir uma visão mais detalhada das possíveis permutações de execução do programa que você pode encontrar.)

Qual a percentagem a exigir

• 100%. Você pode escolher isso porque você quer ter certeza de que tudo é testado. Isso não lhe dá nenhuma visão sobre a qualidade do teste, mas lhe diz que algum teste de alguma qualidade tocou todas as declarações (ou branch, etc.) Mais uma vez, isto volta ao grau de confiança: se a sua cobertura é inferior a 100%, você sabe algum subconjunto do seu código não é testado.
  Alguns podem argumentar que isto é uma tolice, e você só deve testar as partes do seu corpo. código que são realmente importantes. Eu diria que você também deve manter apenas as partes do seu código que são realmente importantes. A cobertura do código pode ser melhorada removendo o código não testado, também.

Outras notas

O acima assume que a correcção é o objectivo. Cobertura de código é apenas informação; pode ser relevante para outros objetivos. Por exemplo, se você está preocupado com a manutenção, você provavelmente se preocupa com o acoplamento solto, o que pode ser demonstrado pela testabilidade, que por sua vez pode ser medido (em certas modas) pela cobertura de código. Assim, o seu padrão de cobertura de código fornece uma base empírica para aproximar a qualidade de "manutenção" também.

O processo subjacente é:

1. Eu escrevo os meus testes para exercitar todas as funcionalidades e casos de ponta que eu possa pensar (normalmente trabalhando a partir da documentação).
2. Eu corro as ferramentas de cobertura de código
3. eu examino quaisquer linhas ou caminhos não coberto e qualquer que eu considere Não importante ou inalcançável (devido à programação defensiva) eu marco como não contando
4. escrevo novos testes para cobrir as linhas em falta e melhorar a documentação se esses casos não forem mencionados.

Scott Hanselman respondeu com palavras sábias.:

São os 20% certos? São os 20% isso representa o código de seus usuários mais? Você poderia adicionar mais 50 testes e adicionar apenas 2%.

• as linhas Cobertas não são iguais à lógica testada e não se deve ler demasiado na percentagem.

Ao usar a métrica de cobertura de código você não deve ter apenas uma porcentagem fixa (arbitrária) que deve ser cumprida.Fazer isto não lhe dá os benefícios reais da cobertura de código. análise na minha opinião. Em vez disso, defina as seguintes métricas:

• Marca de água baixa( LWM), o menor número de linhas não descobertas alguma vez vistas no sistema em ensaio
• Marca de água elevada( HWM), a percentagem de cobertura de código mais elevada alguma vez observada para o sistema em ensaio

O novo código só pode ser adicionado se não subirmos o LWM e não subirmos o HWM. Por outras palavras, a cobertura do código é proibida de diminuir , devendo ser abrangido um novo código. Repare como eu dizer deve e não deve (explicado abaixo).

• O código testável é promovido. Adicionar novo código você realmente tem que fazer um esforço para tornar o código testável, porque você terá que tentar cobrir tudo isso com seus casos de teste. O código testável normalmente é uma coisa boa.

• A cobertura do teste para o código legado está aumentando ao longo do tempo. Ao adicionar um novo código e não ser capaz de cobri-lo com um caso de teste, pode-se tentar cobrir algum código legado em vez de contornar a regra LWM. Isto às vezes necessária batota pelo menos dá o efeito colateral positivo que a cobertura de o código legado irá aumentar com o tempo, tornando a aplicação aparentemente rigorosa destas regras bastante pragmática na prática.

E mais uma vez, se o ciclo de feedback for demasiado longo, pode ser completamente impraticável configurar algo como isto no processo de integração.

• A análise de cobertura de código é parte da análise dinâmica de código (em oposição à estática, ou seja, a fieira). Problemas encontrados durante a análise dinâmica do código (por ferramentas como a família purify, http://www-03.ibm.com/software/products/en/rational-purify-family ) são coisas como leituras de memória não inicializadas( UMR), vazamentos de memória, etc. estes problemas só podem ser encontrados se o código for coberto por um caso de teste executado. O código que é o mais difícil de cobrir em um caso de teste é geralmente os casos anormais no sistema, mas se você quiser que o sistema falhe graciosamente (ou seja, rastreamento de erro em vez disso de crash) você pode querer colocar algum esforço para cobrir os casos anormais na análise de código dinâmico também. Com um pouco de azar, um UMR pode levar a uma segfault ou pior.

• As pessoas se orgulham em manter 100% para o novo código, e as pessoas discutem problemas de teste com uma paixão semelhante a outros problemas de implementação. Como esta função pode ser escrita de forma mais testável? Como é que tentarias cobrir este caso anormal?, etc.

E um negativo, para completar.

Num grande projecto com muitos programadores envolvidos, nem todos vão ser um génio dos testes, com certeza. algumas pessoas tendem a usar a métrica de cobertura de código como prova de que o código é testado e isto está muito longe da verdade, como mencionado em muitas das outras respostas a esta pergunta. É uma métrica que pode dar-lhe alguns benefícios agradáveis se usado corretamente, mas se for mal utilizado ele pode, de fato, levar a maus testes. Além dos efeitos secundários muito valiosos mencionados acima, uma linha coberta apenas mostra que o sistema sob teste pode alcançar essa linha para alguns dados de entrada e que pode executar sem pendurar ou bater.

Muitas lojas não valorizam os testes, por isso, se você está acima de zero, pelo menos há alguma apreciação do valor - então, indiscutivelmente não-zero não é mau, como muitos ainda são zero.

Conclusão: aplica a regra 80:20, e deixa a contagem de erros da tua aplicação guiar-te.

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Se tens feito testes unitários durante um tempo decente, não vejo razão para não estar perto de 95%+. No entanto, no mínimo, eu sempre trabalhei com 80%, mesmo quando novo para testes.

Este número só deve incluir o código escrito no projecto (exclui quadros, plugins, etc.) e talvez até excluir certas classes compostas inteiramente de código escrito de chamadas para código exterior. Este tipo de chamada deve ser ridicularizada.

A cobertura do Código é grande, mas apenas desde que os benefícios que você obtém dele superem o custo/esforço para alcançá-lo.

Check out Crap4j . É uma abordagem um pouco mais sofisticada do que uma cobertura de código simples. Ele combina medidas de cobertura de código com medidas de complexidade, e então mostra que código complexo não é testado atualmente.

A minha resposta a este enigma é ter uma cobertura de linha de 100% do código que pode testar e uma cobertura de linha de 0% do código que não pode testar.

Minha prática atual em Python é dividir o meu .py módulos em duas pastas: app1/ e app2/ e quando executar testes de unidade calcular a cobertura desses dois pastas e verificar visualmente (I tem automatizar isso um dia) que app1 tem 100% de cobertura e app2 tem 0% de cobertura.

Quando / se eu descobrir que estes números diferem da norma Investigo e altero o desenho do código para que a cobertura esteja de acordo com o padrão.

Eu também revejo ocasionalmente o app2/ para ver se posso testar qualquer código lá, e se posso transferi-lo para o app1/

Com python, eu deveria ser capaz de criar um teste de fumaça que poderia executar automaticamente o meu aplicativo ao medir a cobertura e, espero, ganhar uma aggreagate de 100% ao combinar o teste de fumaça com figuras mais inadequadas.

Ver a cobertura de outra perspectiva: código bem escrito com um fluxo claro de controle é o mais fácil de cobrir, o mais fácil de ler, e geralmente o código menos buggy. Ao escrever código com clareza e cobertura em mente, e ao escrever os testes da unidade em paralelo com o código, você obtém os melhores resultados IMHO.

Normalmente sigo os seguintes critérios ou Regras:

1. Que o teste de unidade deve ser uma forma de documentação sobre o comportamento esperado dos meus códigos, ou seja. a saída esperada dada uma determinada entrada e as exceções que pode lançar que os clientes podem querer pegar (o que os usuários do meu código devem saber?)

2. Que o teste de unidade deve ajudar-me a descobrir e se as condições que eu ainda não pensei. (Como tornar meu código estável e robusto?)

A resposta também depende da história do seu projecto. Eu só achei o acima para ser prático em projetos gerenciados dessa forma desde o início. Eu ... melhorou muito a cobertura de grandes projetos legados, e valeu a pena fazê-lo, mas eu nunca achei prático voltar atrás e preencher todas as lacunas de cobertura, porque o código antigo não testado não é bem entendido o suficiente para fazê-lo corretamente e rapidamente.

Depende muito da sua aplicação. Por exemplo, algumas aplicações consistem principalmente de código GUI que não pode ser testado unit.

Resposta Curta: 60-80%

Resposta longa: Acho que depende totalmente da natureza do teu projecto. Eu normalmente começo um projeto por unidade testando cada peça prática. No primeiro" lançamento " do projeto você deve ter uma boa porcentagem de base com base no tipo de programação que você está fazendo. Nesse ponto você pode começar a "impor" uma cobertura mínima de código.

Dependendo da criticidade do Código, qualquer lugar de 75% -85% é uma boa regra de ouro. Código de envio deve definitivamente ser testado mais completamente do que em utilitários da casa, etc.

Se você já esteve em desenvolvimento por um tempo e tem um monte de código implementadas já e só agora percebendo que você precisa pensar sobre a cobertura de código, em seguida, você tem que verificar sua cobertura atual (se ele existir) e, em seguida, usar essa linha de base para definir os marcos de cada sprint (ou uma subida média ao longo de um período de sprints), o que significa tomar sobre o código de dívida, enquanto continua a fornecer valor de usuário final (pelo menos na minha experiência o usuário final não se importa um pouco se você aumentou a cobertura de teste se eles não vêem novos recursos).

Tínhamos como alvo > 80% até alguns dias atrás, mas depois que usamos um monte de código gerado, não nos importamos com a idade%, mas sim fazer o revisor tomar uma chamada sobre a cobertura necessária.