Testy E2E z agentem AI: błędy łapiesz, zanim zobaczy je klient

31 października 2026 Towards Data Science opublikowało poradnik o testach end-to-end, w których agent AI klika po aplikacji tak, jak zrobiłby to użytkownik. Autor twierdzi, że to, co dawniej było żmudną ręczną robotą, dziś da się zlecić jednym promptem. Tekst jest dla każdego, kto buduje aplikację z Claude Code lub Codex, także gdy kod pisze za niego agent. Poniżej opisuję, co autor deklaruje i jak wygląda to krok po kroku. Liczb ani wyników pomiarów w poradniku nie ma, więc to relacja z podejścia, nie z testu.

Czym jest test end-to-end i co właściwie wyłapuje agent AI?

Test end-to-end (w skrócie E2E) sprawdza gotową aplikację, a nie pojedyncze fragmenty kodu. Agent widzi ekran, decyduje, w który przycisk kliknąć, klika i patrzy, co pojawiło się na następnej stronie. Potem zgłasza problem: błąd po kliknięciu, przycisk, który nic nie robi, albo sytuację, w której oczekiwana akcja po prostu się nie wydarzyła.

Autor uzasadnia to prosto. Agenci kodujący świetnie piszą kod, ale zdarza im się coś przeoczyć albo napisać zawiły kod z nieoczekiwanymi skutkami ubocznymi. Test E2E nie interesuje się tym, jaki kod uruchomiono. Patrzy na końcowy produkt, taki, jaki widzi użytkownik.

Dlaczego dawne testy E2E tak bardzo męczyły?

Według autora trzeba je było tworzyć ręcznie. Przechodziłeś przez każdą stronę, podawałeś testowi identyfikator przycisku do kliknięcia i zapisywałeś, co ma się stać po kliknięciu. Już na starcie była to żmudna robota.

Gorsza była konserwacja. Zmieniasz wygląd strony albo jakąś logikę, a testy trzeba poprawiać. Autor nazywa to dość poważnym kosztem utrzymania, który ciągnie się przez cały czas życia testu. Mój komentarz: test, któremu sam wskazujesz każdy przycisk, to ankieta, w której sam wpisujesz odpowiedzi respondentom. Znajdzie tylko te błędy, które już przewidziałeś.

Dziś, jak opisuje autor, test E2E to agent z dostępem do przeglądarki (albo komputera) i planem działania. Na przykład: dojdź do strony A, wykonaj akcję B, oczekiwany wynik to C. Agenta nie trzeba aktualizować po zmianie wyglądu strony, o ile przycisk nadal na niej jest. Autor dodaje, że takie testy są bardziej ogólne, więc wykrywają problemy, których wąskie dawne testy nie łapały, i łatwo ich stworzyć więcej.

Jak ustawić agenta testowego bez programowania testów od zera?

Krok 1: daj agentowi przeglądarkę

Agent musi mieć dostęp do przeglądarki. Autor podaje jako przykład Playwright MCP, czyli narzędzie, które pozwala agentowi sterować wybraną przeglądarką. Pisze, że u niego działa bardzo dobrze i nie wracał do innych rozwiązań, ale dopuszcza, że istnieją skuteczniejsze, których nie próbował.

Krok 2: opisz ścieżkę użytkownika promptem

Potem prosisz agenta, żeby przygotował test dla konkretnej ścieżki. Przykład z poradnika to strona przeglądu zespołu:

• zwykły użytkownik ma widzieć tylko siebie i swoje statystyki (np. godziny w platformie, liczbę kliknięć),
• admin ma widzieć całą drużynę, łącznie ze sobą, w tabeli z tymi samymi statystykami.

Agent testowy dostaje zwykle te same uprawnienia i reguły co prawdziwy użytkownik. Zwykłego użytkownika i admina reprezentują więc dwaj osobni agenci, a całość konfiguruje jeden prompt. To nie magia, tylko system: opis oczekiwanego zachowania zamiast listy identyfikatorów.

Krok 3: postaw testy na niezawodnej maszynie

Przy pierwszym podejściu autor radzi uruchamiać testy na serwerze, który się nie wywala. Może to być osobna maszyna w chmurze, GitHub Actions runner albo Mac mini stojący gdzieś w kącie. Sposób uruchamiania, np. natywny harmonogram Maca albo zadania cykliczne (Cron jobs) w Vercelu, według autora wybierze za Ciebie agent kodujący, na przykład Claude lub Codex.

Kiedy uruchamiać testy: przed wdrożeniem i co godzinę?

Autor wymienia dwa momenty i sam używa obu:

• Przed scaleniem kodu do dev lub produkcji. Scalenie to włączenie nowego kodu do działającej wersji. Test jest wtedy częścią potoku CI/CD, czyli automatycznej bramki przed wdrożeniem.
• Cyklicznie na dev i produkcji. Autor odpala pakiet co godzinę, żeby wychwycić problemy, które nie biorą się ze zmian w kodzie. Jego przykład to zmiana zmiennych środowiskowych, czyli ustawień aplikacji trzymanych poza kodem.

To drugie ma sens z prostego powodu: aplikacja potrafi się zepsuć, mimo że nikt nie ruszył ani linijki kodu. Gdy agent pisze za Ciebie dużą część programu, dobrze mieć kogoś, kto sprawdza efekt. Podobny wątek, czyli system wokół modelu, który decyduje o jakości pracy agenta, rozwijamy w tekście o harness engineering. A jeśli korzystasz z kilku agentów naraz, zobacz, jak DeepSeek Harness zleca zadania Codex i Claude Code.

Co jest deklaracją autora, a gdzie sprawdzisz koszty i ryzyka?

Autor zachęca, by wdrożyć testy E2E dla wszystkich funkcji i stron, bo są jego zdaniem relatywnie tanie w uruchamianiu i pomagają mu odkrywać wiele problemów. To opinia, bez liczb. Realny koszt zobaczysz w cenniku narzędzi, z których korzystasz (Claude Code, Codex, Playwright MCP), i w dokumentacji ich dostawców. Pamiętaj też, że agent z dostępem do przeglądarki to agent z uprawnieniami, więc dawaj mu te same prawa co zwykłemu użytkownikowi, nie więcej. O tym, jak łatwo zaufanie do agenta bywa wykorzystane, przeczytasz w historii o tym, jak AGENTS.md w Download nakłonił Codex i Claude Code do malware. Jeśli dopiero uczysz się pracy z Claude Code, zerknij na kurs Claude Code i koszt planu Pro.

Według autora ręczne wypisywanie przycisków i oczekiwanych wyników przestaje być potrzebne, bo ścieżkę możesz opisać zwykłym językiem. Weź swoją aplikację, stronę albo formularz i zapisz w notatniku trzy najważniejsze ścieżki użytkownika według schematu: strona A, akcja B, oczekiwany wynik C (osobno dla zwykłego użytkownika i, jeśli jest, admina). Dostaniesz gotowy materiał na prompt dla agenta testowego.