Jaki jest najlepszy sposób działania w TDD, jeśli po prawidłowym zaimplementowaniu logiki test nadal się nie powiedzie (ponieważ w teście jest błąd)?
Załóżmy na przykład, że chcesz rozwinąć następującą funkcję:
int add(int a, int b) {
return a + b;
}
Załóżmy, że rozwijamy go w następujących krokach:
Test zapisu (jeszcze brak funkcji):
// test1 Assert.assertEquals(5, add(2, 3));Powoduje błąd kompilacji.
Napisz implementację funkcji fikcyjnej:
int add(int a, int b) { return 5; }Wynik:
test1zalicza się.Dodaj kolejny przypadek testowy:
// test2 -- notice the wrong expected value (should be 11)! Assert.assertEquals(12, add(5, 6));Wynik:
test2zawodzi,test1nadal mija.Napisz prawdziwą implementację:
int add(int a, int b) { return a + b; }Wynik:
test1nadal mija,test2nadal nie działa (od11 != 12).
W tym konkretnym przypadku: czy lepiej byłoby:
- popraw
test2i zobacz, że teraz mija, lub - usuń nową część implementacji (tj. wróć do kroku 2 powyżej), popraw
test2i pozwól, aby zakończyła się niepowodzeniem, a następnie ponownie wprowadź poprawną implementację (krok # 4 powyżej).
A może jest jakiś inny, mądrzejszy sposób?
Rozumiem, że przykładowy problem jest dość trywialny, ale interesuje mnie, co robić w ogólnym przypadku, który może być bardziej złożony niż dodanie dwóch liczb.
EDYCJA (W odpowiedzi na odpowiedź @Thomas Junk):
W centrum tego pytania jest to, co sugeruje TDD w takim przypadku, a nie „uniwersalna najlepsza praktyka” do uzyskania dobrego kodu lub testów (które mogą być inne niż sposób TDD).