O que é uma razoável cobertura de código% para testes de unidade (e porquê)? [fechadas]

StackOverflow https://stackoverflow.com/questions/90002

Pergunta

Se você fosse para impor um código de cobertura percentual mínimo para testes de unidade, talvez até mesmo como um requisito para se comprometer com um repositório, o que seria?

Por favor, explique como chegou a sua resposta (uma vez que se tudo que você fez foi escolher um número, então eu poderia ter feito isso sozinho;)

Foi útil?

Solução

Esta prosa por Alberto Savoia responde precisamente a essa pergunta (de uma forma bem divertida para isso!):

http://www.artima.com/forums/flat. jsp? fórum = 106 & thread = 204677

Testivus Na Cobertura de Teste

Numa manhã bem cedo, um programador perguntou o grande mestre:

“Eu estou pronto para escrever alguns testes de unidade. O que a cobertura de código que deve ter como objectivo para?”

O grande mestre respondeu:

“Não se preocupe com a cobertura, basta escrever alguns testes bons.”

O programador sorriu, inclinou-se e esquerda.

...

Mais tarde naquele dia, um segundo programador fez a mesma pergunta.

O grande mestre apontou para um pote de água fervente e disse:

“Quantos grãos de arroz que eu deveria colocar nessa panela?”

O programador, parecendo confusa, respondeu:

“Como eu posso possivelmente dizer? Depende de quantas pessoas você precisa alimentação, como fome são, o que outro alimento que você está servindo, quanto arroz você tem disponível, e assim por diante.”

“Exatamente”, disse o grande mestre.

O segundo programador sorriu, curvou-se, e à esquerda.

...

Para o fim do dia, um terço programador veio e pediu o mesmo pergunta sobre a cobertura de código.

“Oitenta por cento e não menos!” Respondeu o mestre em uma voz severa, batendo com o punho na mesa.

O terceiro programador sorriu, curvou-se, e à esquerda.

...

Após esta última resposta, um jovem aprendiz se aproximou da grande mestre:

“Grande mestre, hoje eu ouvi você responder a mesma pergunta sobre cobertura de código com três diferentes respostas. Por quê?”

O grande mestre se levantou de sua cadeira:

“Venha pegar um pouco de chá fresco comigo e vamos falar sobre isso.”

Depois encheram seus copos com fumar chá verde quente, o grande mestre começou a resposta:

“O primeiro programador é novo e apenas começando com o teste. Agora ele tem um monte de código e não testes. Ele tem um longo caminho a percorrer; incidindo sobre a cobertura de código neste momento seria deprimente e bastante inútil. Ele é melhor apenas para se acostumar escrever e executar alguns testes. Ele pode preocupação sobre a cobertura mais tarde “.

“O segundo programador, por outro lado, é bastante experiência tanto na programação e testes. Quando eu respondeu, perguntando-lhe como muitos grãos do arroz devo colocar em uma panela, I a ajudou a perceber que a quantidade de testando necessário depende de uma série de fatores, e ela conhece os factores melhor do que eu - que é ela código depois de tudo. Não há um único, simples, resposta, e bastante inteligente ela de para lidar com a verdade e trabalhar com isso.”

“Eu vejo”, disse o jovem aprendiz, “Mas se não há uma única simples resposta, então por que você responder à terceiro programador ‘Oitenta por cento e não menos “?

O grande mestre riu tão duro e alto que sua barriga, evidência de que ele bebeu mais do que apenas chá verde, baqueou cima e para baixo.

“O terceiro programador quer apenas respostas simples - mesmo quando há Não há respostas simples ... e depois não faz segui-los de qualquer maneira.”

O jovem aprendiz eo grisalho grande mestre terminou de beber sua chá em silêncio contemplativo.

Outras dicas

cobertura de código é uma cobertura enganosa métrica se 100% é o seu objetivo (em vez de% de testes de todos os recursos 100).

  • Você pode obter uma 100% por bater todas as linhas de uma só vez. No entanto, você ainda pode perder testando uma seqüência particular (caminho lógico) em que essas linhas são atingidos.
  • Você não poderia obter um 100%, mas ainda testei todos os seus 80% / freq código-caminhos usados. Tendo testes que teste de cada 'jogar ExceptionTypeX' ou similar guarda programação defensiva que você colocou no é um 'bom ter' e não um 'must have'

Então confie em si mesmo ou seus desenvolvedores para ser completa e cobrir todos os caminhos através de seu código. Ser pragmático e não perseguir a cobertura mágico de 100%. Se você TDD seu código, você deve obter um 90% + cobertura como um bônus. Use de cobertura de código para pedaços de destaque do código que você perdeu (não deve acontecer se você TDD embora .. desde que você escrever o código apenas para fazer uma passagem de teste. Nenhum código pode existir sem seu teste parceiro.)

cobertura

Código é grande, mas a cobertura funcionalidade é ainda melhor. Eu não acredito na cobertura de cada linha que escrevo. Mas eu acredito, por escrito, a cobertura do teste 100% de toda a funcionalidade que eu quero para fornecer (mesmo para o frio recursos extras que veio com mim e que não foram discutidos durante as reuniões).

Eu não me importo se eu tiver um código que não é coberto em testes, mas eu me importaria se eu refatorar meu código e acabam por ter um comportamento diferente. Portanto, 100 a cobertura funcionalidade% é o meu único alvo.

A resposta aceita faz um ponto bom - não há um único número que vai fazer sentido como um padrão para cada projeto. Há projetos que simplesmente não precisa, tais padrão a. Onde a resposta aceita fica aquém, na minha opinião, é na descrição de como se poderia tomar essa decisão para um determinado projeto.

Eu vou tomar um tiro em fazê-lo. Eu não sou um especialista em engenharia de testes e ficaria feliz em ver uma resposta mais informada.

Quando estabelecer requisitos de cobertura de código

Em primeiro lugar, por que você quer impor esse padrão um, em primeiro lugar? Em geral, quando você quer introduzir confiança empírica em seu processo. O que quero dizer com "confiança empírica"? Bem, o objetivo real correção . Para a maioria dos softwares, que não pode saber isso em todas as entradas, de modo que se contentar com dizer que o código é bem testado . Isso é mais cognoscível, mas ainda é um padrão subjetivo: Será sempre aberto ao debate se ou não você se encontrou com ele. Esses debates são úteis e devem ocorrer, mas eles também expõem incerteza.

A cobertura de código é uma medida objetiva: Depois de ver seu relatório de cobertura, não há ambigüidade sobre se foram cumpridos os padrões são úteis. Será que provar correção? Nem por isso, mas tem uma relação clara de quão bem-testado o código é, que por sua vez é a nossa melhor maneira de aumentar a confiança na sua correção. cobertura de código é uma aproximação mensurável de qualidades incomensuráveis ??nos preocupamos.

Alguns casos específicos em que têm um padrão empírica poderia agregar valor:

  • Para satisfazer as partes interessadas. Para muitos projectos, existem vários atores que têm interesse em qualidade de software que não pode estar envolvido no desenvolvimento do dia-a-dia do software (gestores, líderes técnicos , etc.) Dizer "nós estamos indo para escrever todos os testes que realmente precisamos" não é convincente: eles nem precisam confiar inteiramente, ou verificar com a supervisão estreita em curso (assumindo que eles ainda têm o conhecimento técnico para fazê-lo) Proporcionar. padrões mensuráveis ??e explicando como eles objetivos reais razoavelmente aproximados é melhor.
  • Para o comportamento da equipe normalize. Stakeholders lado, se você estiver trabalhando em uma equipe onde várias pessoas estão escrevendo código e testes, não há margem para ambiguidades para o que qualifica como "bem-testado." Todos os seus colegas têm a mesma idéia do que nível de teste é bom o suficiente? Provavelmente não. Como você concilia isso? Encontrar uma métrica que podemos todos concordar sobre e aceitá-la como uma aproximação razoável. Isto é especialmente (mas não exclusivamente) útil em grandes equipes, onde leads podem não ter controle direto sobre desenvolvedores junior, por exemplo. Redes de confiança assunto bem, mas sem medidas objetivas, é fácil para o comportamento do grupo para se tornar inconsistente, mesmo que todo mundo está agindo de boa fé.
  • Para manter-se honesto. Mesmo se você for o único desenvolvedor e somente as partes interessadas para o seu projeto, você pode ter certas qualidades em mente para o software. Em vez de fazer avaliações subjetivas em curso sobre quão bem-testado o software é (o que dá trabalho), você pode usar a cobertura de código como uma aproximação razoável, e deixe máquinas medi-lo para você.

Quais métricas de usar

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

Vou usar duas métricas comuns como exemplos de quando você pode usá-los para estabelecer padrões:

  • cobertura de declaração : Qual a percentagem de declarações foram executadas durante os testes? Útil para ter uma noção da cobertura física do seu código: Como grande parte do código que eu escrevi que eu realmente testado?
    • Este tipo de sup coberturaportas de um argumento de correção mais fraco, mas também é mais fácil de alcançar. Se você está apenas usando a cobertura de código para garantir que as coisas são testados (e não como um indicador da qualidade do teste, além disso), então a cobertura de declaração é provavelmente suficiente.
  • cobertura de Núcleo : Quando não está ramificando lógica (por exemplo, uma if), têm ambos os ramos foram avaliados? Isto dá uma noção melhor da cobertura lógica do seu código: Como muitos dos possíveis caminhos meu código pode demorar tenho testado?
    • Este tipo de cobertura é um melhor indicador muito que um programa foi testado através de um conjunto abrangente de entradas. Se você estiver usando a cobertura de código como seu melhor aproximação empírica para a confiança na correção, você deve definir normas com base na cobertura ramo ou similar.

Existem muitas outras métricas (cobertura de linha é semelhante à cobertura de declaração, mas produz resultados diferentes numéricos para as demonstrações de várias linhas, por exemplo, a cobertura condicional e cobertura do trajeto é semelhante à cobertura ramo, mas refletem uma visão mais detalhada do permutações possíveis de execução do programa que você pode encontrar.)

Qual a percentagem de exigir

Por fim, de volta à pergunta original:? Se você definir padrões de cobertura de código, o que deve esse número seja

Esperamos que está claro neste momento que estamos a falar de uma aproximação para começar, portanto, qualquer número que escolher vai ser inerentemente aproximada.

Alguns números que se pode escolher:

  • 100% . Você pode escolher essa porque você quer ter certeza de que tudo é testado. Isso não lhe dá qualquer visão sobre a qualidade do teste, mas não dizer que algum teste de alguma qualidade tocou cada declaração (ou ramo, etc.) Novamente, isso vem de volta para grau de confiança: Se a sua cobertura é inferior a 100% , você sei algum subconjunto de seu código não foi testado.
    • Alguns podem argumentar que isso é bobagem, e você só deve testar as partes do código que são realmente importantes. Eu diria que você também só devem manter as partes do código que são realmente importantes. cobertura de código pode ser melhorado através da remoção de código não testado também.
  • 99% (ou 95%, outros números no alto dos anos noventa.) Adequadas em casos onde você deseja transmitir um nível de confiança semelhante a 100%, mas deixar-se uma margem para não se preocupar com o canto ocasional-to hard-teste de código.
  • 80% . Eu vi este número em uso algumas vezes, e não inteiramente saber onde ela se origina. I pensar pode ser uma apropriação indevida estranho da regra 80-20; em geral, a intenção aqui é mostrar que mais do seu código é testado. (Sim, 51% também seria "mais", mas 80% é mais reflexivo do que a maioria das pessoas média pela maioria.) Isto é apropriado para casos do solo meio onde "bem testados" não é uma alta prioridade (você não quer desperdiçar esforço em testes de baixo valor), mas é o suficiente de uma prioridade que você ainda gostaria de ter algum padrão no lugar.

Eu não vi números inferiores a 80%, na prática, e ter um tempo difícil imaginar um caso em que se poderia defini-las. O papel destas normas é aumentar a confiança na exatidão, e números inferiores a 80% não são particularmente-confiança inspirando. (Sim, isso é subjetivo, mas, novamente, a idéia é fazer a escolha subjetiva, uma vez quando você definir o padrão, e então usar uma medida objetiva daqui para frente.)

Outras notas

O acima assume que a correção é o objetivo. 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 preocupam com baixo acoplamento, que pode ser demonstrada pela capacidade de teste, que por sua vez pode ser medido (em certas modas) pela cobertura de código. Portanto, o seu código de cobertura standard fornece uma base empírica para aproximar a qualidade de "manutenção" também.

Meu cobertura de código favorito é 100% com um asterisco. O asterisco vem porque eu prefiro usar ferramentas que permitem me para marcar certas linhas como linhas que "não contam". Se eu cobri 100% das linhas que "contam", eu sou feito.

O processo subjacente é:

  1. Eu escrevo meus testes para exercer todos os casos de funcionalidade e de ponta que eu posso pensar (em geral, trabalhando a partir da documentação).
  2. I executar as ferramentas de cobertura de código
  3. examino todas as linhas ou caminhos não cobertos e qualquer que eu não consideram importante ou inacessível (devido à programação defensiva) Eu como não marca a contagem
  4. I escrever novos testes para cobrir as linhas em falta e melhorar a documentação, se esses casos extremos não são mencionados.

Desta forma, se eu e meus colaboradores adicionar um novo código ou alterar os testes no futuro, há uma linha clara de nos dizer se perdemos algo importante - a cobertura caiu abaixo de 100%. No entanto, ele também oferece a flexibilidade para lidar com diferentes prioridades de teste.

eu teria outro anectode na cobertura de teste que eu gostaria de compartilhar.

Nós temos um enorme projeto que, através do Twitter, notei que, com 700 testes de unidade, só ter 20% de cobertura de código .

Scott Hanselman respondeu com palavras de sabedoria :

É o DIREITO de 20%? É a 20% que representa o código de seus usuários bateu mais? Você pode adicionar 50 a mais testes e só adicionar 2%.

Mais uma vez, ele vai voltar para o meu Testivus na cobertura de código Resposta. Quanto arroz você deve colocar no pote? Depende.

Se este fosse um mundo perfeito, 100% do código seria coberta por testes de unidade. No entanto, uma vez que este não é um mundo perfeito, é uma questão do que você tem tempo para. Como resultado, eu recomendo concentrando-se menos em uma porcentagem específica, e concentrando-se mais nas áreas críticas. Se seu código está bem escrito (ou pelo menos um fac-símile razoável do mesmo) deve haver vários pontos-chave onde APIs estão expostos a outro código.

Concentre seus esforços de teste sobre essas APIs. Certifique-se de que as APIs são: 1) bem documentado e 2) têm casos de teste escrito que correspondam à documentação. Se os resultados esperados não corresponder-se com os docs, então você tem um bug em ambos os casos código, documentação, ou de teste. Tudo o que é bom para o veterinário.

Boa sorte!

Para um sistema bem projetado, onde testes de unidade têm impulsionado o desenvolvimento desde o começo Eu diria que 85% é um número bastante baixo. Turmas pequenas projetado para ser testável não deve ser difícil para cobrir melhor do que isso.

É fácil descartar essa questão com algo como:

  • linhas cobertas não igual testado lógica e não se deve ler muito sobre o percentual.

É verdade, mas há alguns pontos importantes a serem feitas sobre a cobertura de código. Na minha experiência, essa métrica é realmente muito útil, quando utilizado corretamente. Dito isto, eu não vi todos os sistemas e tenho certeza que há toneladas de lhes onde é difícil ver a análise de cobertura de código adicionando qualquer valor real. Código pode parecer tão diferente e o âmbito do quadro teste disponível pode variar.

Além disso, o meu raciocínio diz respeito, principalmente, loops de feedback de teste bastante curtas. Para o produto que estou desenvolvendo o ciclo de feedback mais curto é bastante flexível, cobrindo tudo, desde testes de classe para a sinalização processo Inter. Testando um sub-produto liberado normalmente leva 5 minutos e durante o ciclo de feedback curto é realmente possível usar os resultados do teste (e especificamente a cobertura de código métrica que estamos vendo aqui) para rejeitar ou aceitar commits no repositório.

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

  • Baixo Mark Água (LWM), o menor número de linhas a descoberto jamais visto no sistema em teste
  • High Mark Água (HWM), o maior percentual de cobertura de código já vi para o sistema em teste

Novo código só pode ser adicionado, se não ultrapassar o LWM e nós não ir abaixo da HWM. Em outras palavras, a cobertura de código é não tem permissão para diminuir , e novo código deve ser coberto. Observe como eu digo deve e não deve (explicado abaixo).

Mas Isso não significa que será impossível para limpar afastado velho-testado bem lixo que você não tem nenhum uso para mais? Sim, e é por isso que você tem que ser pragmático sobre essas coisas. Há situações em que as regras têm de ser quebrado, mas para sua integração normal do dia-a-dia minha experiência, que essas métricas são bastante úteis. Eles dão o seguinte duas implicações.

  • código Testable é promovido. Ao adicionar um novo código que você realmente tem que fazer um esforço para fazer o testável código, porque você vai ter que tentar e cobrir tudo com seus casos de teste. código testável geralmente é uma coisa boa.

  • A cobertura de teste para código legado está aumentando ao longo do tempo. Ao adicionar 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. Esta batota às vezes necessário, pelo menos, dá o efeito colateral positivo que a cobertura de código legado vai aumentar ao longo do tempo, fazendo com que a aplicação aparentemente estrito destas regras bastante pragmática em prática.

E, novamente, se o ciclo de feedback é muito longo, pode ser completamente impraticável para configurar algo parecido com isso no processo de integração.

Eu também gostaria de mencionar dois benefícios mais gerais da cobertura de código métrica.

  • análise de cobertura de código é parte da análise dinâmica de código (em oposição ao um estático, ou seja, Lint). Problemas encontrados durante a análise dinâmica de código (por ferramentas tais como a família purificar, http://www-03.ibm.com/software/products/en/rational-purify-family ) são coisas como a memória não inicializada lê (UMR), vazamentos de memória, etc. Estes problemas podem só pode ser encontrada se o código está coberto por um caso de teste executado . O código que é o mais difícil de cobertura em umcaso de teste é geralmente os casos anormais no sistema, mas se você quer que o sistema falhar normalmente (ou seja, traço erro em vez de falhar) você pode querer colocar algum esforço para cobrir os casos anormais na análise dinâmica de código também. Com apenas um pouco de má sorte, uma UMR pode levar a um segfault ou pior.

  • As pessoas se orgulham de manter 100% para o novo código, e as pessoas discutem testando problemas com uma paixão semelhante como outros problemas de implementação. Como pode esta função ser escrito de uma forma mais testável? Como você iria sobre a tentativa de cobrir este caso anormal, etc.

E um negativo, para ser completo.

  • Em um grande projeto com muitos desenvolvedores envolvidos, todos não vai ser um teste-gênio com certeza. Algumas pessoas tendem a usar a cobertura de código métrica como prova de que o código é testado e isso é muito longe da verdade , como mencionado em muitas das outras respostas para essa pergunta. É uma métrica que pode dar-lhe alguns benefícios agradáveis ??se usado corretamente, mas se for mal utilizado ele pode na verdade levar ao mau testes. Para além dos efeitos secundários muito valiosos mencionados acima uma linha coberta apenas mostra que o sistema em teste pode chegar a essa linha para alguns dados de entrada e que pode executar sem desligar ou deixar de funcionar.

85% seria um bom ponto de partida para critérios de check-in.

eu provavelmente escolheu uma variedade de bares mais elevados para o transporte de critérios -. Dependendo da criticidade dos subsistemas / componentes sendo testado

Muitas lojas não testes de valor, então se você estiver acima de zero pelo menos há alguma apreciação de valor -. Por isso, sem dúvida, diferente de zero não é ruim como muitos ainda são zero

No .NET mundo as pessoas costumam citar 80% como reasonble. Mas eles dizem isso no nível da solução. I preferem medir ao nível do projecto: 30% pode ser bom para o projeto de UI se você tem selênio, etc ou testes manuais, 20% para o projeto da camada de dados pode ser bom, mas 95% + pode ser bastante viável para o negócio governa camada, se não totalmente necessário. Assim, a cobertura global pode ser, digamos, 60%, mas a lógica de negócios crítica pode ser muito maior.

Eu também já ouvi isso: aspire a 100% e você vai bater 80%; mas aspirar a 80% e você vai bater 40%.

A linha inferior:. Aplicar a regra 80:20, e deixe contagem de bugs do seu aplicativo guiá-lo

Eu uso cobertura, e qualquer que seja a percentagem, eu recomendaria manter os valores na tarefa cobertura-check up-to-date. No mínimo, continuar a aumentar totallinerate e totalbranchrate até um pouco abaixo de sua cobertura atual, mas não diminuir esses valores. Também amarrar na propriedade falha de construção Ant para esta tarefa. Se a construção falhar devido à falta de cobertura, você sabe código adicionado de alguém, mas não testou-lo. Exemplo: 

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

Quando eu acho que meu código não é unidade testada o suficiente, e eu não tenho certeza do que teste seguinte, eu usar cobertura para me ajudar a decidir o que teste seguinte.

Se eu aumentar a cobertura em um teste de unidade -. Eu sei que isso vale a pena teste de unidade algo

Isso vale para código que não é coberto, 50% cobertos ou 97% de cobertura.

A cobertura de código é apenas uma outra métrica. Em si, ele pode ser muito enganosa (ver www.thoughtworks .com / percepções / blog / são de testes de cobertura de métricas-superestimada ). Seu objetivo não deve, portanto, ser para atingir a cobertura de código 100%, mas sim para garantir que você testar todos os cenários relevantes de sua aplicação.

Se você está fazendo testes de unidade para uma quantidade razoável de tempo, não vejo razão para não estar se aproximando de 95% +. No entanto, no mínimo, eu sempre trabalhei com 80%, mesmo quando novo para testes.

Este número deve incluir apenas o código escrito no projeto (estruturas exclui, plugins, etc.) e talvez até mesmo excluir determinadas classes de compostos inteiramente de código escrito de chamadas para código fora. Este tipo de chamada deve ser escarnecido / apagou.

De um modo geral, a partir da vários excelência em engenharia melhores práticas papéis que eu li, 80% para o novo código em testes de unidade é o ponto que os rendimentos o melhor retorno. Indo de cima que CC% produz uma menor quantidade de defeitos para a quantidade de esforço exercido. Esta é uma prática recomendada que é usado por muitas grandes empresas.

Infelizmente, a maioria destes resultados são internos às empresas, para que não haja literaturas públicas que posso apontar-lhe.

A cobertura de código é grande, mas apenas enquanto os benefícios que você começa a partir dele superam o custo / esforço de alcançá-la.

Temos vindo a trabalhar a um nível de 80% durante algum tempo, no entanto, temos apenas fez a decison a abandonar este e em vez disso ser mais focados em nosso teste. Concentrando-se na lógica de negócios complexos etc,

Esta decisão foi tomada devido ao aumento da quantidade de tempo que passamos perseguindo cobertura de código e manutenção de testes de unidade existentes. Nós sentimos que tínhamos chegou a um ponto em que o benefício que estávamos recebendo da nossa cobertura de código foi considerado menor que o esforço que tivemos que colocar-se para alcançá-lo.

Eu prefiro fazer BDD, que usa uma combinação de testes automatizados de aceitação, possivelmente, outros testes de integração e testes de unidade. A questão para mim é o que a cobertura alvo da suite de testes automatizados como um todo deve ser.

Quanto ao resto, a resposta depende de sua metodologia, linguagem e testando e ferramentas de cobertura. Ao fazer TDD em Ruby ou Python não é difícil para manter a cobertura de 100%, e vale a pena fazê-lo. É muito mais fácil de gerir uma cobertura de 100% do que por cento de cobertura 90 e poucos anos. Ou seja, é muito mais fácil para preencher lacunas de cobertura como eles aparecem (e ao fazer TDD assim lacunas de cobertura são raras e geralmente vale o seu tempo ) do que está a gerir uma lista de lacunas de cobertura que você não tenha chegado a cerca de e regressões de cobertura perder devido à sua formação constante de código descoberto.

A resposta depende também da história de seu projeto. Eu só encontrei o acima para ser prático em projetos gerenciados dessa forma desde o início. Eu tenho melhorado muito a cobertura de grandes projetos de legado, e tem sido vale a pena fazê-lo, mas eu nunca encontrei-lo prático para voltar e preencher todas as lacunas de cobertura, porque o código não testado idade não é bem compreendido o suficiente para fazê-lo corretamente e rapidamente.

Confira Crap4j . É uma abordagem um pouco mais sofisticado do que a cobertura de código em linha reta. Ele combina medições de cobertura de código com medidas de complexidade, em seguida, mostra-lhe o código complexo não está testado.

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

A minha prática atual em Python é dividir meus módulos py em duas pastas: app1 / e App2 / e quando testes de unidade em execução calcular a cobertura dessas duas pastas e verificar visualmente (I deve Automatizar este um dia) que app1 tem 100% de cobertura e app2 tem 0% de cobertura.

Quando / se eu achar que estes números diferem de investigage padrão I e alterar o design do código de modo que se conforma a cobertura para o padrão.

isso não significa que eu posso recomendar alcançar 100% de cobertura de linha de código da biblioteca.

Eu também, ocasionalmente, rever app2 / para ver se eu poderia possível teste de qualquer código lá, e Se eu posso movê-lo em app1 /

Agora, eu não estou muito preocupado com a cobertura agregada porque isso pode variar muito, dependendo do tamanho do projeto, mas geralmente eu vi 70% a mais de 90%.

Com python, eu deveria ser capaz de conceber um teste de fumaça que pode executar automaticamente meu aplicativo ao medir a cobertura e espero ganhar uma aggreagate de 100% quando se combina o teste de fumaça com figuras unittest.

Visualizando cobertura de outra perspectiva: Código de Bem-escrito com um claro fluxo de controle é o mais fácil de cobertura, o mais fácil de ler, e geralmente o código menos buggy. Ao escrever código com clareza e coverability em mente, e por escrever os testes de unidade em paralelo com o código, você obter os melhores resultados IMHO.

Na minha opinião, a resposta é "Depende de quanto tempo você tem". I tentar alcançar 100%, mas eu não fazer um barulho se eu não obtê-lo com o tempo que tenho.

Quando eu escrever testes de unidade, eu usar um chapéu diferente em comparação com o desgaste chapéu I ao desenvolver código de produção. Eu penso sobre o que as reivindicações código testado para fazer e quais são as situações que pode possível quebrá-lo.

Eu costumo seguir os seguintes critérios ou regras:

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

  2. Que o teste de unidade deve me ajudar a descobrir o que se as condições que eu ainda não pode ter pensado. (Como fazer meu estável código e robusta?)

Se essas duas regras não produz uma cobertura de 100%, então que assim seja. Mas uma vez, eu tenho o tempo, analiso os blocos e linhas de descobertas e determinar se ainda existem casos de teste sem testes de unidade ou se as necessidades de código para ser reformulado para eliminar os códigos desnecessários.

Depende muito da sua aplicação. Por exemplo, alguns aplicativos consistem principalmente de código GUI que não pode ser testado unidade.

Eu não acho que pode ser um B / regra como W.
Código deve ser revisto, com especial atenção para os detalhes críticos.
No entanto, se ele não foi testado, tem um bug!

Resposta curta: 60-80%

A resposta mais completa: Eu acho que depende totalmente da natureza do seu projeto. Eu normalmente iniciar um projeto por unidade testar cada peça prático. Pelo primeiro "lançamento" do projeto que você deve ter uma porcentagem boa base muito com base no tipo de programação que você está fazendo. Nesse ponto, você pode começar a "impor" uma cobertura de código mínimo.

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

Isso tem que ser dependente do que fase do seu desenvolvimento de aplicações de ciclo de vida em que está.

Se você já esteve em desenvolvimento por um tempo e tem um monte de código implementado já e só agora estão percebendo que você precisa pensar sobre a cobertura de código, em seguida, você tem que verificar a sua cobertura atual (se existir) e, em seguida, uso essa linha de base para os objetivos intermédios definidos cada sprint (ou um aumento médio ao longo de um período de sprints), o que significa tomar sobre a dívida código enquanto continua a oferecer valor ao usuário final (pelo menos na minha experiência ao usuário final não se importa nem um pouco se você' ve aumento da cobertura de teste se eles não vêem novos recursos).

Dependendo do seu domínio não é razoável a disparar para 95%, mas eu teria que dizer que, em média, o seu vai estar a olhar para um processo médio de 85% para 90%.

Eu acho que o melhor sintoma de cobertura de código correto é que a quantidade de problemas concretos testes de unidade ajuda a correção é razoavelmente corresponde ao tamanho do código testes de unidade que você criou.

Eu acho que o que pode ser mais importante é saber o que a tendência cobertura é ao longo do tempo e compreender as razões para mudanças na tendência. Se você visualizar as mudanças na tendência como bom ou ruim vai depender da sua análise da razão.

Nós foram alvo> 80% até alguns dias atrás, mas depois foi utilizado um monte de código gerado, Nós não nos importamos para a idade%, mas sim fazer revisor tomar uma chamada sobre a cobertura necessária.

A partir da postagem Testivus Eu acho que o contexto resposta deve ser o segundo programador. Dito isto de um ponto de vista prático, precisamos de parâmetros / metas que lutar. Considero que esta pode ser "testada" em um processo ágil, analisando o código, temos os arquitetura, funcionalidade (as histórias de usuário) e, em seguida, chegar a um número. Baseado na minha experiência na área de Telecom Eu diria que 60% é um bom valor para verificar.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top