Jest bardziej niż prawdopodobne, że osiągnąłeś liczbę 65 miliardów testów, obliczając wszystkie możliwe kombinacje danych wejściowych do testowanego systemu lub obliczając cykliczną złożoność i zakładając, że test musi być napisany dla każdej z tych unikalnych ścieżek wykonania.
Nie tak pisane są prawdziwe testy, ponieważ jak wskazali inni plakaty i komentatorzy, siła techniczna wymagana do wykonania 65 miliardówtesty są oszałamiające. To byłoby jak napisanie testu, który ćwiczy metodę dodawania dwóch liczb całkowitych poprzez podłączenie każdej możliwej permutacji dwóch 32-bitowych wartości i sprawdzenie wyniku. To całkowite szaleństwo. Musisz narysować linię i zidentyfikować podzbiór wszystkich możliwych przypadków testowych, które między nimi zapewniłyby, że system będzie zachowywał się zgodnie z oczekiwaniami w całym zakresie danych wejściowych. Na przykład. testujesz dodając kilka „zwykłych” liczb, testujesz kilka scenariuszy z liczbą ujemną, testujesz ograniczenia techniczne, takie jak scenariusze przepełnienia, i testujesz wszelkie scenariusze, które powinny spowodować błąd. Jak wspomniano, te różne typy testów wykonują „klasy równoważności”; pozwalają pobrać reprezentatywną próbkę możliwych danych wejściowych wraz ze wszelkimi znanymi „wartościami odstającymi”,
Rozważ jedną z podstawowych katas kodu, generator liczb rzymskich. Zadaniem, które należy wykonać przy użyciu technik TDD w stylu „dojo”, jest napisanie funkcji, która może przyjąć dowolną liczbę od 1 do 3000 i wygenerować poprawną liczbę rzymską dla tej wartości liczbowej.
Nie rozwiązujesz tego problemu, pisząc 3000 testów jednostkowych, jeden po drugim, i przekazując je kolejno. To szaleństwo; ćwiczenie zwykle trwa od jednej do dwóch godzin i będziesz tam przez kilka dni testując każdą indywidualną wartość. Zamiast tego stajesz się mądry. Zaczynasz od najprostszego przypadku bazowego (1 == „I”), zaimplementuj go za pomocą strategii „najmniej kodu” ( return "I";), a następnie sprawdź, jak kod będzie się zachowywał niepoprawnie w innym oczekiwanym scenariuszu (2 == ” II ”). Wypłukać i powtórzyć; bardziej niż prawdopodobne, zastąpiłeś swoją początkową implementację czymś, co powtarza znak „I” tak często, jak to konieczne (jak return new String('I',number);). To oczywiście przejdzie test na III, więc nie przejmuj się; zamiast tego piszesz test dla 4 == „IV”, o którym wiesz, że bieżąca implementacja wygrała ”
Lub, w bardziej analitycznym stylu, badasz każdą decyzję warunkową podjętą przez kod (lub musi być) i piszesz test mający na celu wprowadzenie kodu dla każdego możliwego wyniku każdej decyzji. Jeśli masz 5 instrukcji if (każda z prawdziwą i fałszywą gałęzią), każda z nich jest w pełni niezależna od drugiej, kodujesz 10 testów, a nie 32. Każdy test będzie miał na celu stwierdzenie dwóch rzeczy dotyczących konkretnej możliwej decyzji; najpierw podjęta jest prawidłowa decyzja, a następnie, że kod został wprowadzony przy spełnieniu tego warunku. Państwo nie kodować test dla każdej możliwej permutacji niezależnych decyzji. Jeśli decyzje są zależne, musisz przetestować ich więcej w kombinacji, ale takich kombinacji jest mniej, ponieważ niektóre decyzje są podejmowane tylko wtedy, gdy inna decyzja przyniosła określony wynik.