Czy test TDD zawsze powinien zakończyć się niepowodzeniem?

Question

Jako kontynuację dyskusji w komentarzach this answer, czy test TDD zawsze musi być zakończony niepowodzeniem?

Rozważmy następujący przykład. Jeśli piszę implementację LinkedHashSet i jeden test testowy, który po wstawieniu duplikatu, oryginał jest w tej samej kolejności iteracji co przed wstawieniem, może chciałbym dodać osobny test, że duplikat w ogóle nie jest w zestawie.

Pierwszy test zostanie zauważony jako pierwszy, a następnie zaimplementowany.

Problem polega na tym, że implementacja pierwszego przejścia testowego wykorzystała inną implementację zestawu do przechowywania danych, więc jako efekt uboczny przechodzi już drugi test.

Myślę, że głównym celem testu nie jest zapewnienie, że test jest dobrym testem (wielokrotnie napisałem test, który według mnie może się nie powieść, ale nie, ponieważ test został napisany nieprawidłowo) . Ale jeśli masz pewność, że test, który piszesz, rzeczywiście coś testuje, czy nie jest to cenne, aby upewnić się, że nie złamiesz tego zachowania później?

Answer 1

Oczywiście, że jest cenny, ponieważ wtedy jest przydatny regression test. Moim zdaniem testy regresji są ważniejsze niż testowanie nowo opracowanego kodu.

Powiedzieć, że zawsze muszą zawodzić, to przekraczać praktyczność.

Answer 2

TDD jest dla mnie raczej narzędziem do projektowania, a nie po namyśle. Więc nie ma innej drogi, test zakończy się niepowodzeniem, ponieważ nie ma kodu, który jeszcze umożliwiałby przejście, dopiero po utworzeniu go, że test może kiedykolwiek przejść.

Answer 3

Tak, testy TDD muszą zakończyć się niepowodzeniem, zanim staną się zielone (praca). W przeciwnym razie nie wiesz, czy masz ważny test.

Answer 4

Myślę, że celem "niepowodzenia na początku" jest uniknięcie żartowania, że ​​test zadziałał. Jeśli masz zestaw testów sprawdzających tę samą metodę z różnymi parametrami, jeden (lub więcej) z nich prawdopodobnie przejdzie od samego początku. Rozważmy następujący przykład:

public String doFoo(int param) { 
    //TODO implement me 
    return null; 
} 

Testy byłoby coś jak:

public void testDoFoo_matches() { 
    assertEquals("Geoff Hurst", createBar().doFoo(1966)); 
} 

public void testDoFoo_validNoMatch() { 
    assertEquals("no match", createBar().doFoo(1)); 
} 

public void testDoFoo_outOfRange() { 
    assertEquals(null, createBar().doFoo(-1)); 
} 
public void testDoFoo_tryAgain() { 
    assertEquals("try again", createBar().doFoo(0)); 
} 

Jeden z tych testów minie, ale wyraźnie inni nie, więc trzeba zaimplementować kod odpowiednio dla zestaw testów do zaliczenia. Myślę, że to jest prawdziwy wymóg. Duch reguły polega na upewnieniu się, że myślisz o oczekiwanym wyniku, zanim zaczniesz hackować.

Answer 5

IMHO, najważniejszą przyczyną niepowodzenia jest upewnienie się, że stworzony test nie ma wad. Możesz na przykład zapomnieć o Asercie w teście i być może nigdy nie dowiesz się o tym.

Podobny przypadek występuje, gdy przeprowadzasz testy graniczne, masz już wbudowany kod, który go obejmuje, ale zaleca się przetestowanie tego.

Myślę, że to nie jest duży problem, aby twój test się nie powiódł, ale musisz upewnić się, że rzeczywiście testuje to, co powinien (może debugowanie).

Answer 6

To, o co właściwie pytasz, to jak przetestować test, aby sprawdzić, czy jest on ważny i sprawdza, co zamierzasz.

Włączenie tego błędu jest możliwe, ale pamiętaj, że nawet jeśli nie powiedzie się, gdy planujesz, że zawiedzie i powiedzie się po przeliczeniu kodu, aby odnieść sukces, to nadal nie oznacza, że ​​twój test faktycznie testowałem to, co chciałeś ... Oczywiście możesz napisać kilka innych klas, które zachowują się inaczej, aby przetestować twój test ... Ale to jest faktycznie test, który testuje twój oryginalny test - Skąd wiesz, że test nowy jest ważny? :-)

Wykonywanie pierwszego testu nie jest dobrym pomysłem, ale nadal nie jest niezawodne.