Quais técnicas você realmente usou com sucesso para melhorar a cobertura do código?

Question

Consigo regularmente 100% de cobertura de bibliotecas usando TDD, mas nem sempre, e sempre parece haver partes das aplicações que não são testadas e descobertas.
Depois, há os casos em que você começa com o código legado que tem muito poucos testes e muito pouca cobertura.

Por favor, diga qual é a sua situação e o que funcionou isso pelo menos melhorou cobertura.
Suponho que você esteja medindo a cobertura durante o teste de unidade, mas diga que se você estiver usando outras técnicas.

Answer 1

Excluir código.

Isso não é sarcástico, mas realmente sério. Sempre que eu veria a menor quantidade de duplicação de código ou mesmo código que não consegui executar, eu a excluí. Isso aumentou a cobertura e o aumento da manutenção.

Devo observar que isso é mais aplicável ao aumento da cobertura de bases de código antigas versus novas bases de código.

Answer 2

Eu presumo que você leia "Código coberto vs. Código testado", certo ?

Como declarado nessa questão,

Mesmo com cobertura de bloco 100% + cobertura de arco de 100% + 100% livre de erros para um código linear-line de um pathamento, ainda haverá dados de entrada que executam caminhos/loops de maneiras que exibem mais bugs.

Agora eu uso Eclema, com base em Emma e essa ferramenta de cobertura de código explica por que o código 100% nem sempre é possível: por causa de linhas parcialmente cobertas devido a:

• Ramificações implícitas na mesma linha.
• Código do construtor compartilhado.
• Ramos implícitos devido a finalmente blocos.
• Ramificações implícitas devido a uma classe oculta.ForName ().

Portanto, todos esses 4 casos podem ser bons candidatos para a refatoração, levando a uma melhor cobertura de código.

Agora, eu concordo com a resposta de Frank Krueger. Algum código não coberto também pode ser uma indicação de que alguma refatoração seja feita, incluindo algum código para realmente excluir;)

Answer 3

As duas coisas que tiveram o maior impacto nos projetos em que trabalhei foram:

1. Periodicamente, "lembrando" a equipe de desenvolvimento para implementar os testes de unidade real e revisar como escrever testes eficazes.
2. Gerando um relatório de cobertura geral de teste e circulando isso entre os gerentes de desenvolvimento.

Answer 4

Nós usamos Perl, então Devele :: Cover tem sido muito útil para nós. Mostra cobertura por instrução, cobertura de filial e cobertura condicional durante o teste de unidade, além de coisas como a cobertura do POD. Usamos a saída HTML com verduras fáceis de reconhecer para "100%", através de amarelo e vermelho para níveis mais baixos de cobertura.

EDITAR: Para expandir um pouco as coisas:

• Se a cobertura condicional não estiver concluída, examine as condições para interdependência. Se estiver lá, refator. Se não for, você poderá estender seus testes para atingir todas as condições.
• Se a cobertura condicional e da filial parecer completa, mas a cobertura da declaração não for, você escreveu os condicionais errados (por exemplo, sempre retornando cedo de um sub quando você não quis) ou você tem um código extra que pode ser removido com segurança .

Answer 5

Teste de ajuste melhorou nossa cobertura de código. Foi ótimo porque é uma abordagem totalmente diferente.

Antecedentes: temos uma mistura de legado e novo código. Tentamos testar a unidade/integração as novas coisas o máximo possível, mas como estamos migrando para hibernar/pós -gres e longe de um OODB, não há muito sentido em testar o código legado.

Para quem não sabe, o FIT é uma maneira de testar o software da perspectiva do usuário. Essencialmente, você pode especificar o comportamento desejado nas tabelas HTML: as tabelas especificam as ações contra o software e os resultados desejados. Nossa equipe escreve 'código de cola' (AKA Fit Test) que mapeie as ações para chamadas em relação ao código. Observe que esses testes operam em uma visão 'do espaço' em comparação com os testes de unidade.

Usando essa abordagem, aumentamos nossa cobertura de código em vários pontos percentuais. Um bônus adicional é que esses testes se enrolarão nas versões: eles testarão o código legado, mas depois, posteriormente, novo código. ou seja, eles servem como testes de regressão, em certo sentido.