Mais do que provável, você chegou ao seu número de 65 bilhões de testes calculando todas as combinações possíveis de entradas no sistema em teste ou calculando a complexidade ciclomática e assumindo que um teste deve ser gravado para cada um desses caminhos de execução exclusivos.
Não é assim que os testes reais são escritos, porque, como outros pôsteres e comentadores indicaram, o poder técnico necessário para executar 65 bilhõestestes é impressionante. Isso seria como escrever um teste que exercite um método para adicionar dois números inteiros, conectando todas as permutações possíveis de dois valores de 32 bits e verificando o resultado. É insanidade absoluta. É necessário traçar a linha e identificar um subconjunto de todos os casos de teste possíveis, o que entre eles garantiria que o sistema se comportasse conforme o esperado em toda a gama de entradas. Por exemplo. você testou a adição de alguns números "comuns", alguns cenários de números negativos, limites técnicos como cenários de estouro e todos os cenários que deveriam resultar em erro. Como foi mencionado, esses vários tipos de testes exercem "classes de equivalência"; eles permitem que você colete uma amostra representativa das possíveis entradas, juntamente com os "outliers" conhecidos,
Considere um dos katas de código básico, o Gerador de Números Romanos. A tarefa, a ser executada usando técnicas TDD no estilo "dojo", é escrever uma função que possa aceitar qualquer número de 1 a 3000 e produzir o número romano correto para esse valor numérico.
Você não resolve esse problema escrevendo 3000 testes de unidade, um de cada vez, e passando-os sucessivamente. Isso é loucura; o exercício normalmente leva entre uma e duas horas e você fica lá por dias testando cada valor individual. Em vez disso, você fica esperto. Você começa com o caso base mais simples (1 == "I"), implementa isso usando uma estratégia de "código mínimo" ( return "I";) e depois procura como o código que você possui se comportará incorretamente em outro cenário esperado (2 == " II "). Enxague e repita; mais do que provável, você substituiu sua implementação inicial por algo que repete o caractere "I" quantas vezes for necessário (como return new String('I',number);). Obviamente, isso passará em um teste para III, para que você não se incomode; em vez disso, você escreve o teste para 4 == "IV", que você sabe que a implementação atual ganhou '
Ou, em um estilo mais analítico, você examina cada decisão condicional tomada pelo código (ou precisa ser) e escreve um teste desenvolvido para inserir o código para cada resultado possível de cada decisão. Se você tiver cinco instruções if (cada uma com uma ramificação verdadeira e falsa), cada uma delas totalmente independente da outra, você codifica 10 testes, não 32. Cada teste será projetado para afirmar duas coisas sobre uma possível decisão específica; primeiro que a decisão correta é tomada e, em seguida, que o código digitado, desde que a condição esteja correta. Você não codifica um teste para cada permutação possível de decisões independentes. Se as decisões são dependentes, é necessário testar mais delas em combinação, mas há menos combinações, porque algumas decisões só são tomadas quando outra decisão tem um resultado específico.