Automaty to placebo
Pięć sygnałów, że Twoje testy niczego nie chronią
Ostatnio przeglądałem zestaw testów automatycznych w jednym z projektów i złapałem się na czymś nieprzyjemnym. Pokrycie było przyzwoite, pipeline świecił się na zielono, struktura repozytorium wyglądała jak podręcznikowy przykład dobrej automatyzacji. Po godzinie czytania kodu okazało się, że spora część tych testów nie chroniła nas przed niczym konkretnym.
To był dobry moment na trudniejsze pytanie: czy te testy faktycznie coś sprawdzają, czy tylko dają nam poczucie, że coś sprawdzają? To dwie różne rzeczy, a różnica między nimi bywa kosztowna, bo fałszywe poczucie bezpieczeństwa jest gorsze niż jawny brak testów. Kiedy wiesz, że czegoś nie masz, testujesz to ręcznie przed wdrożeniem, a kiedy masz zielony raport, po prostu klikasz "deploy".
Zebrałem pięć sygnałów, po których poznasz, że Twoje automaty są drogim placebo. Żaden z nich osobno nie oznacza katastrofy, bo każdy projekt ma jakieś długi techniczne i świadome kompromisy. Jeśli jednak rozpoznajesz u siebie dwa albo trzy naraz, warto zrobić audyt zanim zrobi go za Ciebie produkcja.
Zielony pipeline nie jest dowodem jakości
Najczęstszy błąd w rozmowie o jakości automatów polega na myleniu wykonania kodu z jego weryfikacją. Code coverage - czyli procent linii kodu wykonanych podczas testów - mówi tylko tyle, że dana linia została uruchomiona. Nie mówi nic o tym, czy ktokolwiek sprawdził, jaki był efekt jej wykonania.
W praktyce łatwo to zobaczyć na przykładzie modułu płatności. Test przechodzi całą ścieżkę zakupową, uruchamia kilkaset linii kodu i podbija metrykę pokrycia do poziomu, który dobrze wygląda na spotkaniu z klientem. Jeśli jego jedyną asercją jest sprawdzenie, że po kliknięciu pojawił się nagłówek "Dziękujemy za zamówienie", to ten test przepuści błędnie naliczony rabat, zdublowaną transakcję i zamówienie zapisane bez pozycji.
Metryka pokrycia jest pomocnicza i nadal warto ją zbierać, bo pokazuje białe plamy w repozytorium. Traktowanie jej jako celu samego w sobie kończy się jednak zestawem testów optymalizowanych pod liczbę w raporcie, a nie pod ryzyko na produkcji. Wartość testu mierzy się tym, czy wychwyci konkretną, prawdopodobną awarię - reszta to statystyka.
1. Testujesz wyłącznie happy path
Aplikacja "działa", bo sprawdzasz w niej tylko to, co i tak zawsze działało. Logowanie z poprawnymi danymi, formularz wypełniony dokładnie jak w instrukcji, request z idealnym payloadem przygotowanym przez developera. Przypadki brzegowe i błędne dane wejściowe są w takim zestawie po prostu niewidoczne.
Nikt nie sprawdza, co się stanie, gdy pole zostanie puste, gdy użytkownik wklei emoji tam, gdzie oczekujesz liczby, albo gdy request przyjdzie bez wymaganego nagłówka autoryzacji. Nikt nie sprawdza też sytuacji, które w realnym ruchu zdarzają się codziennie: wygaśnięcia sesji w połowie procesu, podwójnego kliknięcia w przycisk zatwierdzenia czy odpowiedzi z API, która przychodzi po pięciu sekundach zamiast po dwustu milisekundach. Produkcja nie działa według happy path, a użytkownicy robią rzeczy, których nikt w zespole nie przewidział na refinemencie.
Minimalna poprawka, którą polecam wprowadzić jako zasadę w zespole, jest prosta: każda krytyczna ścieżka biznesowa dostaje przynajmniej jeden test negatywny. Jeden test sprawdza, że proces kończy się sukcesem, a drugi - że system poprawnie odmawia i komunikuje to użytkownikowi. To nie podwaja pracy, bo zwykle wystarczy zmiana danych wejściowych i asercji, a wykrywalność błędów rośnie znacząco.
2. Testy nie padają, gdy coś się psuje
To mój ulubiony test na jakość testów. Wprowadź celowy błąd w kodzie produkcyjnym - zmień warunek na przeciwny, usuń walidację pola, odwróć znak w obliczeniach - i sprawdź, czy Twój zestaw to wyłapie. Jeśli po takiej zmianie pipeline nadal jest zielony, to nie masz zabezpieczenia, tylko ikonkę, która nic nie znaczy.
Ta technika ma swoją formalną wersję i nazywa się testowaniem mutacyjnym - narzędzie automatycznie wprowadza drobne zmiany w kodzie i sprawdza, ile z nich "zabiją" istniejące testy. W ekosystemie JavaScript i TypeScript używa się do tego Strykera, ale nawet bez wdrażania kolejnego narzędzia do CI możesz zrobić ćwiczenie ręcznie na jednym module w piętnaście minut. Zwykle najciekawsze wyniki daje przy testach, którym zespół ufa najbardziej.
W moich projektach ten eksperyment kilka razy pokazał to samo: test sprawdzał, że ekran się wyrenderował, a nie że logika biznesowa policzyła cokolwiek poprawnie. Po usunięciu walidacji kwoty formularz nadal się wysyłał, test nadal przechodził, a jedyną osobą, która zauważyłaby problem, byłby użytkownik z ujemnym saldem 😅
3. Asercje są zbyt luźne
"Status 200" to za mało. Taka asercja mówi wyłącznie tyle, że serwer odpowiedział, a nie że odpowiedział poprawnie. Test API, który weryfikuje sam kod odpowiedzi, przepuści połamane dane, brakujące pola i zmieniony format daty, o ile tylko backend zdąży cokolwiek zwrócić.
Sensowna asercja w teście API sprawdza strukturę odpowiedzi i jej zawartość: czy schemat się zgadza, czy pola wymagane są obecne, czy typy danych są zgodne z kontraktem. Do walidacji schematu można użyć bibliotek takich jak Zod czy Ajv i wpiąć je bezpośrednio w testy, zamiast ręcznie porównywać po jednym polu. W testach UI ten sam problem wygląda inaczej - sprawdzasz, że element jest widoczny, ale nie sprawdzasz, czy zawiera właściwą treść, więc pusty komunikat błędu przechodzi tak samo dobrze jak poprawny.
Ten sygnał wyraźnie nasilił się od czasu, gdy zespoły zaczęły generować testy z pomocą modeli językowych. AI domyślnie proponuje asercje "bezpieczne", czyli takie, które prawie zawsze przechodzą, bo statystycznie tak wygląda większość kodu w internecie. Jeśli nie wiesz, co powinno być zweryfikowane w danym scenariuszu, dostaniesz szybko dużo testów, które nie potrafią zawieść.
Playwright Starter Pack - zacznij od gotowych fundamentów 🎯
Największy czas w automatyzacji nie ginie na pisanie testów, tylko na research - jaką strukturę projektu wybrać, jak ułożyć Page Object Model, żeby nie rozjechał się po trzech sprintach, i jak w ogóle zabrać się za Playwrighta z głową.
Playwright Starter Pack to konkretny punkt wyjścia: sprawdzona struktura projektu, przykładowe testy i checklista dobrych praktyk, które normalnie zbiera się metodą prób i błędów przez pierwsze miesiące pracy z narzędziem.
4. Testy są zależne od siebie
Jeden pada, reszta pada za nim i nie wiesz, co naprawdę nie działa. Dostajesz dziesięć czerwonych wyników, a realny problem jest jeden, gdzieś na początku łańcucha - najczęściej w teście, który tworzył dane dla wszystkich pozostałych. Zamiast namierzyć przyczynę w minutę, przekopujesz się przez logi i próbujesz zrozumieć, które z tych czerwonych testów w ogóle mają znaczenie.
Dobry test automatyczny jest niezależny, czyli ma własne dane, własny setup i własny teardown, a jego wynik mówi dokładnie o jednej rzeczy. Najtańszy sposób na osiągnięcie tego stanu to przygotowanie danych przez API zamiast przez interfejs użytkownika - konto testowe zakładane requestem jest szybsze, stabilniejsze i nie psuje się przy każdej zmianie w formularzu rejestracji. Współdzielone konto testowe, do którego loguje się cały zestaw, prędzej czy później zamieni się w źródło losowych awarii.
Jest prosty sposób, żeby sprawdzić, czy Twoje testy są naprawdę niezależne: uruchom je równolegle i w losowej kolejności. Playwright robi to domyślnie przy wielu workerach, więc wystarczy zwiększyć równoległość i zobaczyć, co się posypie. Testy, które przechodzą tylko w jednym, konkretnym porządku, nie są zestawem regresyjnym, tylko skryptem odtwarzającym jedną sesję.
5. Nikt nie patrzy na wyniki w CI
Ostatni sygnał jest najbardziej organizacyjny i moim zdaniem najgroźniejszy. Pipeline bywa zielony dlatego, że część testów jest pomijana przez skip, retry ustawiono na trzy próby i wystarczy jedno szczęśliwe przejście, albo dlatego, że wszyscy przyzwyczaili się do czerwonego i przestali sprawdzać. Nawet najlepiej napisany test nie daje nic, jeśli jego wynik nie wpływa na żadną decyzję.
Jeśli status buildu nie decyduje o tym, czy zmiana trafia na produkcję, to nie masz bramki jakości, tylko rytuał wdrożony kiedyś z dobrymi intencjami. Sprawdzenie tego zajmuje jedno pytanie na retrospektywie: kiedy ostatni raz czerwony pipeline zatrzymał wdrożenie? Jeśli nikt nie pamięta, odpowiedź już znasz.
Naprawa zaczyna się od rzeczy nudnych i organizacyjnych, a nie od kolejnego frameworka. Wyniki testów potrzebują właściciela, kanału, na który trafiają automatycznie, limitu retry ustawionego świadomie oraz kwarantanny dla flaky testów - czyli testów przechodzących raz na jakiś czas bez zmian w kodzie - z konkretnym terminem naprawy albo usunięcia. Bez tego liczba pomijanych testów rośnie miesiąc po miesiącu i nikt nie zauważa momentu, w którym zestaw przestał cokolwiek chronić.
Jak sprawdzić to u siebie w jeden wieczór
Nie potrzebujesz do tego zgody zespołu, budżetu ani nowego narzędzia. Wystarczy jeden moduł, najlepiej ten najbardziej krytyczny biznesowo, i dwie godziny spokoju. Wyniki takiego przeglądu są zwykle dobrym materiałem na rozmowę z zespołem, bo operują na konkretach z Waszego repozytorium, a nie na ogólnych zasadach z konferencji.
Proponuję taką kolejność:
Wybierz jedną krytyczną ścieżkę i policz, ile testów sprawdza w niej scenariusze negatywne.
Wprowadź celowy błąd w kodzie tej ścieżki i sprawdź, czy testy padną.
Przejrzyj asercje w pięciu losowych testach i zaznacz te, które sprawdzają wyłącznie fakt załadowania lub kod odpowiedzi.
Uruchom zestaw równolegle i w losowej kolejności, a potem zobacz, ile testów przestało przechodzić.
Sprawdź w historii CI, kiedy ostatni raz czerwony wynik faktycznie zatrzymał wdrożenie.
Jeśli automaty piszesz w Playwrightcie, przy okazji takiego przeglądu przydaje się ściągawka z locatorami i asercjami pod ręką - większość poprawek z tej listy sprowadza się do zamiany słabego selektora na stabilny i do wzmocnienia asercji. Przygotowałem darmowy Playwright Starter Pack - czterdziestostronicowy PDF z komendami, locatorami, asercjami i przykładami kodu, który możesz trzymać otwarty obok edytora.
Test jest wart tyle, ile decyzji na nim opartych
Wszystkie pięć sygnałów sprowadza się do jednego mechanizmu: zestaw testów rośnie szybciej niż zaufanie do jego wyników. Testy powstają, bo tak wypada, bo Definition of Done tego wymaga, bo pokrycie ma nie spaść poniżej ustalonego progu. Nikt nie pyta, przed jaką konkretną awarią chroni nas dany scenariusz, a to jedyne pytanie, które realnie porządkuje pracę nad automatyzacją.
Zielona ikonka jest sygnałem tylko wtedy, gdy potrafi zmienić kolor z powodu, który da się nazwać. Dopóki nie wiesz, jaki błąd musiałby się pojawić, żeby Twój test padł, masz w repozytorium kod, który kosztuje czas na utrzymanie i nie zwraca w zamian informacji o ryzyku. Warto to sprawdzić wcześniej niż w dniu, w którym klient zgłosi błąd w procesie pokrytym "w stu procentach".
Testowanie to coś więcej niż klikanie, ale automatyzacja to też coś więcej niż pisanie testów. To decyzja o tym, co, gdzie i na jakim poziomie warto weryfikować, a potem konsekwencja w pilnowaniu, żeby wyniki tych weryfikacji miały wpływ na to, co trafia na produkcję.
Przestań składać wiedzę o Playwright + AI z przypadkowych źródeł 🤖
Można uczyć się metodą "obejrzę dziesięć różnych tutoriali i sam poskładam całość", tylko że w praktyce zajmuje to tygodnie, a i tak zostają dziury - zwłaszcza tam, gdzie AI zaczyna generować kod, którego nie rozumiesz.
Mini-kurs Playwright + AI prowadzi Cię krok po kroku: od fundamentów frameworka, przez świadome korzystanie z AI przy pisaniu testów, po budowę stabilnego, skalowalnego projektu automatyzacji.
Polecane wpisy:
Sprawdź też moje social media:
Dziękuję, że czytasz mojego bloga!
Masz jakieś pytania? Z chęcią odpowiem :)
Kontakt
kontakt@rwasik.pl