Odpowiedź.

Testy automatyczne dzielimy na jednostkowe (unit), integracyjne (integration) oraz end-to-end (end-to-end, E2E), aby kompleksowo pokryć weryfikację systemu na różnych poziomach.

Historia pytania: Ta klasyfikacja pojawiła się z powodu potrzeby testowania aplikacji zarówno w częściach, jak i w całości. W związku z tym wyróżniamy warstwy testowania:

konkretna funkcja (unit)
interakcja części (integration)
cały system działający od strony użytkownika (E2E)

Problem: Błędy często występują nie tylko w logice pojedynczej metody, ale także na styku komponentów lub podczas "rzeczywistego" uruchamiania całego systemu z zewnętrznymi usługami. Jeśli wszystko zrzuci się do jednej puli, trudno szybko zlokalizować błąd lub zrozumieć, gdzie dokładnie on się pojawił.

Rozwiązanie:

Testy jednostkowe sprawdzają izolowany kod, zazwyczaj na poziomie funkcji lub prostych klas. W bardziej zaawansowanych przypadkach używa się mocków i stubów.
Testy integracyjne łączą kilka komponentów (np. moduł i bazę danych), aby zobaczyć, jak działają razem.
Testy end-to-end (E2E) symulują scenariusze użytkownika — całą drogę "od przycisku do rezultatu".

Rozróżnianie typów testów jest kluczowe, aby:

Zminimalizować koszty wsparcia (testy E2E są drogie)
Zapewnić szybką informację zwrotną (testy jednostkowe są błyskawiczne)
Zmniejszyć liczbę fałszywych alarmów

Kluczowe cechy:

Prawidłowe rozłożenie testów pomaga budować niezawodne podejście "piramidowe" (piramida testów).
Mieszanie stylów testowania prowadzi do problemów z lokalizacją błędów.
Jasne zrozumienie celu każdej warstwy prowadzi do maksymalnej efektywności.

Pytania z pułapką.

Czy można uznać testy integracyjne za "większe" testy jednostkowe?

Nie, testy integracyjne sprawdzają działanie kilku komponentów razem, a nie tylko pojedyncze funkcje. Przy tym nie zawsze można używać mocków — rzeczywiste usługi komunikują się ze sobą.

Czy wszystkie testy powinny być skrajne (E2E)?

Nie, to drogie i skomplikowane podejście. E2E są potrzebne tylko dla krytycznych scenariuszy użytkowników, większość logiki pokrywają inne testy.

Czy testy jednostkowe są zawsze szybkie?

Nie zawsze. Zdarza się, że nie można izolować kodu, lub metoda zależy od skomplikowanych zasobów zewnętrznych. W takim przypadku test przestaje być jednostkowy.

Typowe błędy i antywzorce

Wszystkie testy są pisane tylko jako skrajne, co prowadzi do bardzo powolnej informacji zwrotnej.
Zamieszanie w warstwach: test jednostkowy zaczyna wywoływać bazę danych lub API, a E2E budują się na mockach.
Zostawiają tylko testy jednostkowe — problematyczne błędy na styku komponentów nie są wykrywane.

Przykład z życia

Negatywny przypadek

W firmie pokryto główną funkcjonalność tylko testami E2E — każda poprawka była sprawdzana w nocy, testy padały niestabilnie, błędy były odkrywane późno.

Zalety:

Prawdziwe scenariusze użytkowników są pokryte.

Wady:

Powolna informacja zwrotna.
Długi czas analizy przyczyn awarii.
Wiele fałszywych alarmów.

Pozytywny przypadek

Zespół zbudował piramidę testową: dół — testy jednostkowe, środek — testy integracyjne, góra — tylko najważniejsze E2E.