Skip to content

Piekielne Testy Jednostkowe

Zwykle testami jednostkowymi nazywa się wszystko co jest uruchamiane z poziomu JUnit. W większości przypadków nie są to testy jednostkowe, ale testy integracyjne, których utrzymanie i wytworzenie jest znacznie trudniejsze niż testów jednostkowych. Paul Wheaton wskazuje jakie korzyści osiągamy stosując rzeczywiste testy jednostkowe. Paul proponuje następujące definicje w stosunku do pojęć związanych z testami:
Test jednostkowy (Unit Test)
Test nie mający kontaktu z bazą danych, serwerem aplikacyjnym, systemem plików, inną aplikacją, konsolą, mechanizmem logowania. Sprawdza zwykle jedną wybraną metodę izolując ją od innych obiektów poprzez obiekty Mock.
Zbiór testów regresyjnych (Regression Suite)
Kolekcja testów która może być uruchomiona " za jednym kliknięciem"
Test Funkcjonalny (Functional Test)
Sprawdza wiele metod / klas.
Test Integracyjny (Integration Test)
Sprawdza kilka komponentów współpracujących ze sobą.
Test Komponentu (Component Test)
Sprawdza działanie wybranego komponentu. Nie należy do zbioru testów regresyjnych.
Akceptacyjny Test Komponentu (Component Acceptance Test)
Formalny proces oceny pracy komponentu przez kilka osób.
Test Systemowy (System Test)
Wszystkie komponenty uruchomione razem.
Systemowy Test Akceptacyjny (System Acceptance Test)
Formalny proces oceny pracy systemu (wszystkie komponenty połączone razem) przez kilka osób.
Test Obciążeniowy (Stress Test)
Sprawdzenie działania komponentu(ów) uruchomionych pod zwiększonym obciążeniem.
(Mock)
Obiekt "udający" inny obiekt mający na celu odseparowanie obiektu podlegającego testom od innych obiektów.
(Shunt)
Podobny do obiektu Mock, ale nie izolujący w całości kodu od środowiska.

Problem zbyt wielu testów funkcjonalnych

Typowym objawem korzystania z testów funkcjonalnych zamiast testów jednostkowych jest liczba testów jakie zawodzą kiedy w kodzie pojawi się błąd: Przy prawidłowo utworzonych testach jednostkowych sytuacja będzie następująca:

Nieporozumienia na temat testów jednostkowych

"Pisząc tylko testy jednostkowe piszą mniej kodu testowego, a sprawdzam więcej kodu produkcyjnego"
Prawda, ale za cenę zwiększenia kruchości projektu. Także niektóre scenariusze są dużo trudniejsze do uruchomienia tylko w testach integracyjnych. Najlepsze pokrycie kodu można osiągnąć tylko poprzez odpowiednie połączenie testów jednostkowych z testami integracyjnymi.
"Logika biznesowa opiera się na współpracujących klasach, więc testowanie klasy w odosobnieniu jest bezcelowe"
Paul sugeruje testowanie wszystkich metod, ale oddzielnie. Zwraca uwagę, że testy integracyjne także mają swoją wartość.
"Nie przeszkadza mi, że uruchomienie zestawu testów zajmuje kilka minut"
Duży czas wykonania testów skłania do rzadszego uruchamiania testów i może z czasem prowadzić do zaprzestania uruchamiania testów (nikomu nie będzie sie chciało czekać na efekty).
"Test jednostkowy to każdy test uruchomiony przez JUnit"
Można uruchamiać testy integracyjne i systemowe korzystając z biblioteki JUnit.