E2E tests i visual regression tests: pełna ścieżka użytkownika

Co to za rodzaj testu

E2E test sprawdza kompletną ścieżkę przez system.

W aplikacji webowej zwykle oznacza:

przeglądarka
frontend
backend
baza danych
zewnętrzne integracje albo ich kontrolowane fake

Nie chodzi o to, żeby sprawdzić każdy przypadek.

Chodzi o to, żeby potwierdzić, że krytyczna ścieżka naprawdę składa się w działający system.

Przykłady:

logowanie
zakup
utworzenie konta
reset hasła
publikacja wpisu
przejście przez onboarding

Dlaczego E2E nie może być wszystkim

E2E jest drogie.

Jest wolniejsze niż testy niższych warstw.

Ma więcej możliwych przyczyn porażki.

Zależy od danych, środowiska, czasu, przeglądarki, sieci, animacji i integracji.

Jeżeli E2E próbuje zastąpić unit tests, component tests i integration tests, zaczyna łapać wszystko.

błąd walidacji
błąd selektora
błąd migracji
błąd sesji
błąd konfiguracji
timeout zależności

Jeden czerwony test nie mówi wtedy, co się zepsuło.

Mówi tylko, że ścieżka nie przeszła.

Dlatego E2E powinien chronić małą liczbę najważniejszych przepływów.

Acceptance tests

Acceptance test opisuje zachowanie z perspektywy wymagań.

Może być E2E, ale nie musi.

Jego pytanie brzmi:

czy system spełnia warunek akceptacji?

Na przykład:

użytkownik z aktywną subskrypcją może pobrać fakturę
użytkownik bez uprawnień nie widzi panelu admina
zamówienie po płatności trafia do statusu paid

Jeżeli acceptance test jest uruchamiany przez przeglądarkę i przechodzi przez cały system, jest też E2E.

Jeżeli działa na API albo module domenowym, nadal może być acceptance test, ale nie jest E2E.

Visual regression tests

Visual regression test porównuje wygląd.

Najczęściej robi screenshot i porównuje go z zatwierdzonym obrazem.

To łapie błędy, których zwykłe asercje nie widzą:

ucięty tekst
przesunięty layout
zniknięty przycisk
zły kontrast
regresję responsywności

Visual regression test nie mówi, że logika działa.

Mówi, że wygląd zmienił się albo nie zmienił.

To świetne narzędzie przy komponentach, design systemach, landingach, dashboardach i PDF-ach.

Ale tak jak snapshot, wymaga czytania diffu.

Automatyczne zaakceptowanie zmiany obrazu bez obejrzenia różnicy zabija sens testu.

Narzędzie ze stacka

Do E2E i visual regression tests wybrałbym Playwright.

Dobrze pasuje do aplikacji React, bo testuje system przez prawdziwą przeglądarkę, ale daje kontrolę nad kontekstem, storage, requestami i screenshotami.

Do visual regression użyłbym screenshot assertions z Playwrighta.

Do E2E w pipeline trzymałbym mały zestaw krytycznych ścieżek:

login
checkout
uprawnienia
publikacja
reset hasła

Cypress też jest sensowny, ale przy obecnym stacku wybrałbym Playwrighta za multi-browser, równoległość i mocniejsze narzędzia do trace.

Jak ograniczać flaky E2E

Dobry E2E test potrzebuje stabilnego świata.

kontrolowane dane
deterministyczne logowanie
brak zależności od kolejności testów
czekanie na stan, nie na sleep
fake dla zewnętrznych płatności
czyszczenie danych po teście

Najgorszy E2E test czeka 5000 ms i liczy, że środowisko zdąży.

Flaky E2E jest groźny, bo zespół szybko uczy się go ignorować.

A ignorowany czerwony test jest gorszy niż brak testu, bo daje fałszywy rytuał kontroli.

Kiedy E2E jest właściwe

E2E ma sens tam, gdzie awaria przepływu byłaby droga:

rejestracja
płatność
publikacja
uprawnienia
checkout
odzyskiwanie konta

Nie ma sensu robić E2E dla każdej walidacji pola, każdej gałęzi mappera i każdego komunikatu błędu.

Te rzeczy powinny zejść niżej.

E2E jest ostatnim potwierdzeniem, że warstwy naprawdę działają razem.

Następny rodzaj testów odpowiada na inne pytanie: czy błąd, który już raz przeszedł, wróci drugi raz. To są regression tests i smoke tests.