Höchstwahrscheinlich sind Sie zu Ihrer Zahl von 65 Milliarden Tests gelangt, indem Sie alle möglichen Kombinationen von Eingaben in das zu testende System berechnet haben oder indem Sie die zyklomatische Komplexität berechnet haben und davon ausgegangen sind, dass für jeden dieser eindeutigen Ausführungspfade ein Test geschrieben werden muss.
So werden echte Tests nicht geschrieben, denn wie andere Poster und Kommentatoren angedeutet haben, ist die technische Leistung, die erforderlich ist, um 65 Milliarden auszuführenTests ist atemberaubend. Dies wäre wie das Schreiben eines Tests, bei dem eine Methode zum Hinzufügen von zwei Ganzzahlen ausgeführt wird, indem jede mögliche Permutation von zwei 32-Bit-Werten eingegeben und das Ergebnis überprüft wird. Es ist völliger Wahnsinn. Sie müssen die Grenze ziehen und eine Teilmenge aller möglichen Testfälle identifizieren, um sicherzustellen, dass sich das System im gesamten Eingabebereich erwartungsgemäß verhält. Zum Beispiel. Sie testen das Hinzufügen einiger "gewöhnlicher" Zahlen, Sie testen einige Szenarien mit negativen Zahlen, Sie testen technische Grenzen wie Überlaufszenarien und Sie testen alle Szenarien, die zu Fehlern führen sollten. Wie bereits erwähnt, üben diese verschiedenen Arten von Tests "Äquivalenzklassen" aus. Sie ermöglichen es Ihnen, eine repräsentative Stichprobe der möglichen Eingaben zusammen mit allen bekannten "Ausreißern" zu entnehmen.
Betrachten Sie einen der grundlegenden Code-Katas, den Roman Numeral Generator. Die Aufgabe, die mit TDD-Techniken im Dojo-Stil ausgeführt werden muss, besteht darin, eine Funktion zu schreiben, die eine beliebige Zahl von 1 bis 3000 akzeptiert und die richtige römische Zahl für diesen Zahlenwert erzeugt.
Sie können dieses Problem nicht lösen, indem Sie 3000 Komponententests einzeln schreiben und diese der Reihe nach bestehen. Das ist Wahnsinn; Die Übung dauert normalerweise zwischen einer und zwei Stunden, und Sie sind tagelang dort, um jeden einzelnen Wert zu testen. Stattdessen wirst du schlau. Sie beginnen mit dem einfachsten Basisfall (1 == "I"), implementieren diesen mit einer "Least-Code" -Strategie ( return "I";) und prüfen dann, wie sich der Code in einem anderen erwarteten Szenario falsch verhält (2 == " II "). Spülen und wiederholen; Höchstwahrscheinlich haben Sie Ihre ursprüngliche Implementierung durch etwas ersetzt, das das "I" -Zeichen so oft wie nötig (wie return new String('I',number);) wiederholt . Das wird offensichtlich einen Test für III bestehen, also stört es dich nicht; Stattdessen schreiben Sie den Test für 4 == "IV", von dem Sie wissen, dass die aktuelle Implementierung gewonnen hat. '
Oder Sie untersuchen in einem analytischeren Stil jede bedingte Entscheidung, die vom Code getroffen wird (oder getroffen werden muss), und schreiben einen Test, der den Code für jedes mögliche Ergebnis jeder Entscheidung eingibt. Wenn Sie 5 if-Anweisungen haben (jede hat eine wahre und eine falsche Verzweigung), von denen jede völlig unabhängig von der anderen ist, codieren Sie 10 Tests, nicht 32. Jeder Test soll zwei Dinge über eine bestimmte mögliche Entscheidung aussagen; Zuerst, dass die richtige Entscheidung getroffen wurde und dann, dass der unter dieser Bedingung eingegebene Code korrekt ist. Sie nicht einen Test für jede mögliche Permutation von unabhängigen Entscheidungen codieren. Wenn die Entscheidungen abhängig sind, müssen Sie mehr von ihnen in Kombination testen, aber es gibt weniger solche Kombinationen, da einige Entscheidungen nur dann getroffen werden, wenn eine andere Entscheidung ein bestimmtes Ergebnis hatte.