Como as pessoas mantêm seu conjunto de testes?

Em particular, estou curioso sobre os seguintes aspectos:

1. Como você sabe que seus casos de teste estão errados (ou desatualizados) e precisam ser reparados (ou descartados)? Quero dizer, mesmo que um caso de teste se torne inválido, ele ainda pode passar e permanecer em silêncio, o que pode permitir que você acredite falsamente que seu software funciona bem. Então, como você percebe esses problemas em sua suíte de testes?

2. Como você sabe que seu conjunto de testes não é mais suficiente e que novos casos de teste devem ser adicionados? Eu acho que isso tem algo a ver com as alterações de requisitos, mas existe alguma abordagem sistemática para verificar a adequação do conjunto de testes?

Resposta curta: use ferramentas conhecidas que ajudam a manter a qualidade dos casos de teste, como as seguintes ferramentas de cobertura e qualidade de código: Cobertura, PMD, Sonar etc. que ajudarão você a perceber quando um componente crítico do programa não é testado o suficiente. Além disso, escreva testes de integração, com maior probabilidade de serem interrompidos primeiro sempre que algo der errado.

Resposta longa:

Como você sabe que seus casos de teste estão errados (ou desatualizados) e precisam ser reparados (ou descartados)? Quero dizer, mesmo que um caso de teste se torne inválido, ele ainda pode passar e permanecer em silêncio, o que pode permitir que você acredite falsamente que seu software funciona bem. Então, como você percebe esses problemas em sua suíte de testes?

• Usando ferramentas de cobertura de código, como Cobertura , você pode detectar que casos de teste para uma determinada classe ou métodos complexos não são mais suficientes. Você não precisa alcançar 100% de cobertura de código em qualquer lugar e, na maioria dos casos, será difícil de alcançar e não necessariamente útil; mas testes para os aspectos mais críticos de um programa devem ser mantidos com uma meta de pelo menos 80% de cobertura de código.
• Usando ferramentas contínuas de compilação e integração , como Jenkins, das quais gosto muito, em combinação com o plug-in Sonar , você pode definir gatilhos que enviam emails e outros tipos de alertas para as pessoas responsáveis ​​pelas alterações mais recentes. Vários gráficos e estatísticas (o Sonar também usa Cobertura entre muitas outras ferramentas) ajudam os revisores de código e os desenvolvedores de casos de teste a se concentrarem no que é crítico.

Como você sabe que seu conjunto de testes não é mais suficiente e que novos casos de teste devem ser adicionados? Eu acho que isso tem algo a ver com as alterações de requisitos, mas existe alguma abordagem sistemática para verificar a adequação do conjunto de testes?

O que escrevi para a primeira pergunta faz parte da resposta para a sua segunda pergunta. Também adicionarei os seguintes pontos aqui:

• Escreva casos de teste de integração (ou casos "comerciais", se preferir), além de casos de teste. É mais provável que eles sejam alterados / interrompidos primeiro porque geralmente dependem de várias classes / métodos. E como eles quebram com frequência, é menos provável que isso seja esquecido. A única abordagem / metodologia que, pela minha experiência pessoal, ajuda a escrever bons testes é o Desenvolvimento Orientado a Testes . Especialmente se a pessoa que está escrevendo o caso de teste NÃO é a mesma pessoa que está escrevendo o código para ele. Escrever bons casos de teste usando TDD também leva tempo, mas os resultados, pelo menos para mim, foram extremamente satisfatórios.
• Sempre que ocorrer um erro, escreva a correção e o caso de teste que o acompanha. O caso de teste deve cobrir apenas esse bug específico. Como você cobriu completamente o código responsável pelo bug, ele não deve sair novamente.

Realmente não há como garantir que seus casos de teste estejam corretos, exceto concentrando-se muito bem ao criá-los - entendendo o requisito, entendendo o código e certificando-se de que eles concordam. O objetivo de ter um conjunto de testes é que você só precisa fazer isso uma vez e, a partir de então, basta executar novamente os testes e verificar se eles são aprovados, enquanto que sem um conjunto de testes você precisaria se concentrar muito o tempo todo. , ou seja, sempre que você fizer algo em sua base de código. Mas o problema fundamental de ter que garantir que você estava fazendo a coisa certa em primeiro lugar permanece - os computadores simplesmente não são inteligentes o suficiente para nos livrar dessa tarefa.

Portanto, (1) se sua suíte de testes estiver incompleta, não há uma maneira simples de ver isso. A análise de cobertura de código pode provar que algumas linhas de código nunca são executadas, ou seja, que o conjunto é deficiente de alguma forma, mas não a gravidade dessa deficiência e nunca pode provar que é suficiente. Mesmo com 100% de cobertura de código, você não garante que todos os estados relevantesdo sistema são exercidos, e a cobertura completa do estado é inatingível para qualquer sistema realista devido ao número combinatório de estados que poderia existir. Uma boa técnica para garantir que o caso de teste seja pelo menos correto para verificar o que você deseja verificar é escrever o teste, verificar se ele realmente falhou, escrever / alterar o código e verificar se agora passa. Daí o entusiasmo pelo desenvolvimento orientado a testes: ele permite que você tenha certeza de que um teste individual faça a coisa certa e, se você criar toda a sua base de códigos dessa maneira, poderá obter um nível de confiança semelhante, mesmo em um sistema grande.

(2) Um conjunto de testes normalmente se torna insuficiente sempre que os requisitos mudam - você não precisa adivinhar. Se o cliente deseja que algum comportamento específico seja alterado e seus testes sejam bem-sucedidos antes e depois da alteração, é evidente que eles não estavam exercendo esse relacionamento de entrada / saída específico.

Quanto aos sistemas legados que não têm cobertura de teste ou onde você não sabe qual é a cobertura, não há prova formal, mas (aviso aos pais: segue a opinião pessoal!) Falando por experiência própria, é extremamente provável que os testes não são adequados. Quando o teste é visto como uma atividade posterior ao fato, opcional, que melhora a qualidade, mas não é realmente necessária, ela tende a ser incompleta e não sistemática, porque o incentivo para garantir que os testes acompanhem a base de código não é necessário. está aí.