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í.