Isso depende muito da função que você está testando. Conheço muitos casos em que os números individuais não têm um significado especial por conta própria, mas o caso de teste como um todo é construído de maneira pensada e, portanto, tem um significado específico. É isso que alguém deve documentar de alguma forma. Por exemplo, se foo
for realmente um método testForTriangle
que decide se os três números podem ser comprimentos válidos das arestas de um triângulo, seus testes podem ter esta aparência:
// standard triangle with area >0
assertEqual(testForTriangle(2, 3, 4), true);
// degenerated triangle, length of two edges match the length of the third
assertEqual(testForTriangle(1, 2, 3), true);
// no triangle
assertEqual(testForTriangle(1, 2, 4), false);
// two sides equal
assertEqual(testForTriangle(2, 2, 3), true);
// all three sides equal
assertEqual(testForTriangle(4, 4, 4), true);
// degenerated triangle / point
assertEqual(testForTriangle(0, 0, 0), true);
e assim por diante. Você pode melhorar isso e transformar os comentários em um parâmetro de mensagem de assertEqual
, que será exibido quando o teste falhar. Você pode então melhorar isso e refatorar isso em um teste orientado por dados (se sua estrutura de teste suportar isso). No entanto, você faz um favor a si mesmo se colocar uma nota no código porque escolheu esses números e quais dos vários comportamentos que você está testando com o caso individual.
É claro que, para outras funções, os valores individuais para os parâmetros podem ser mais importantes, portanto, usar um nome de função sem sentido como foo
ao perguntar como lidar com o significado dos parâmetros provavelmente não é a melhor idéia. / p>