Plus que probablement, vous êtes parvenu à votre chiffre de 65 milliards de tests en calculant toutes les combinaisons possibles d'entrées dans le système testé, ou en calculant la complexité cyclomatique en supposant qu'un test doit être écrit pour chacun de ces chemins d'exécution uniques.
Ce n’est pas ainsi que sont écrits les vrais tests car, comme d’autres affiches et commentateurs l’ont indiqué, le pouvoir technique nécessaire pour exécuter 65 milliards de dollarsles tests sont stupéfiants. Ce serait comme écrire un test qui utilise une méthode pour ajouter deux nombres entiers en insérant toutes les permutations possibles de deux valeurs 32 bits et en vérifiant le résultat. C'est la folie totale. Vous devez tracer la ligne et identifier un sous-ensemble de tous les tests élémentaires possibles, ce qui garantirait que le système se comportera comme prévu tout au long de la plage d'entrées. Par exemple. vous testez en ajoutant quelques nombres "ordinaires", vous testez quelques scénarios de nombres négatifs, vous testez des limites techniques telles que des scénarios de dépassement de capacité et vous testez tous les scénarios susceptibles de générer une erreur. Comme il a été mentionné, ces différents types de tests exercent des "classes d'équivalence"; ils vous permettent de prendre un échantillon représentatif des entrées possibles, ainsi que de tous les "points aberrants" connus,
Prenons l’un des katas de code de base, le générateur de chiffres romains. La tâche, à exécuter à l'aide de techniques TDD dans un style "dojo", consiste à écrire une fonction pouvant accepter n'importe quel nombre compris entre 1 et 3 000 et générer le nombre correct de chiffres romains pour cette valeur numérique.
Vous ne résolvez pas ce problème en écrivant 3000 tests unitaires, un à la fois, et en les passant à tour de rôle. C'est de la folie. l'exercice prend normalement entre une et deux heures et vous seriez là pendant des jours pour tester chaque valeur individuelle. Au lieu de cela, vous devenez intelligent. Vous commencez par le cas de base le plus simple (1 == "I"), implémentez-le à l'aide d'une stratégie "moindre code" ( return "I";), puis recherchez le comportement incorrect de votre code dans un autre scénario attendu (2 == " II "). Rincer et répéter; Plus que probablement, vous avez remplacé votre implémentation initiale par quelque chose qui répète le caractère "I" aussi souvent que nécessaire (comme return new String('I',number);). Cela passera évidemment un test pour III, alors vous ne vous inquiétez pas; à la place, vous écrivez le test pour 4 == "IV", dont vous connaissez la mise en oeuvre actuelle gagnée '
Ou, dans un style plus analytique, vous examinez chaque décision conditionnelle prise par le code (ou doit l'être) et écrivez un test conçu pour saisir le code correspondant à chaque résultat possible de chaque décision. Si vous avez 5 instructions if (chacune ayant une branche vraie et une branche fausse), chacune d'entre elles étant totalement indépendantes les unes des autres, vous codez 10 tests, et non 32. Chaque test sera conçu pour affirmer deux choses à propos d'une décision possible particulière; tout d'abord que la décision correcte est prise, puis que le code saisi en fonction de cette condition est correct. Vous ne codez pas de test pour chaque permutation possible de décisions indépendantes. Si les décisions sont dépendantes, vous devez en tester plusieurs en combinaison, mais elles sont moins nombreuses car certaines décisions ne sont jamais prises que lorsqu'une autre décision a eu un résultat particulier.