To ważne rozróżnienie, ale niestety nigdy się nie uda. Problem polega na tym, że większość programistów definiuje je z własnego punktu widzenia. Jest to bardzo podobne do debaty nad Plutonem. (Gdyby była bliżej Słońca, czy byłaby to planeta?)
Testowanie jednostkowe jest łatwe do zdefiniowania. Testuje CUT ( testowany kod ) i nic więcej. (No cóż, tak mało więcej, jak to możliwe.) To oznacza kpiny, podróbki i instalacje.
Na drugim końcu spektrum znajduje się to, co wielu ludzi nazywa testowaniem integracji systemów . To testowanie tak dużo, jak to możliwe, ale wciąż szukasz błędów we własnym CUT.
Ale co z ogromną przestrzenią pomiędzy nimi?
- Na przykład, co, jeśli przetestujesz tylko trochę więcej niż CUT? Co jeśli dołączysz funkcję Fibonacciego, zamiast korzystać z urządzenia, które wstrzykujesz? Nazwałbym to testami funkcjonalnymi , ale świat się ze mną nie zgadza.
- A jeśli dołączysz
time()
lub rand()
? A co jeśli zadzwonisz http://google.com
? Nazwałbym to testowaniem systemu , ale znowu jestem sam.
Dlaczego to ma znaczenie? Ponieważ testy systemu są zawodne. Są konieczne, ale czasami zawodzą z przyczyn od Ciebie niezależnych. Z drugiej strony testy funkcjonalne powinny zawsze przechodzić, a nie kończyć się niepowodzeniem; jeśli są szybkie, mogą być równie dobrze używane od samego początku, aby używać programowania sterowanego testami bez pisania zbyt wielu testów do wewnętrznej implementacji. Innymi słowy, myślę, że testy jednostkowe mogą sprawiać więcej kłopotów niż są warte, a ja mam dobre towarzystwo .
Testuję na 3 osiach, ze wszystkimi zerami na testach jednostkowych :
- Testowanie funkcjonalne: głębsze i głębsze używanie prawdziwego kodu w stosie wywołań.
- Testowanie integracji: coraz wyżej w stosie wywołań; innymi słowy, testowanie CUT-a poprzez uruchomienie kodu, który go użyje.
- Testowanie systemu: coraz więcej niepowtarzalnych operacji (harmonogram O / S, zegar, sieć itp. )
Test może z łatwością obejmować wszystkie 3, w różnym stopniu.