Piekielne Testy Jednostkowe
Sat, 22 Mar 2008 21:27:09 +0000
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.