e2e to otwartoźródłowy framework do testów end-to-end aplikacji webowych i mobilnych od firmy TesterArmy (Y Combinator). W jednym teście łączy dwa światy, które do tej pory trzeba było wybierać osobno: klasyczne kroki z lokatorami i asercjami (jak w Playwright) oraz kroki opisane zwykłym zdaniem, które wykonuje agent AI. Licencja Apache-2.0, kod na github.com/tester-army/e2e, dokumentacja na e2e.com/docs. Premiera była 1 października 2026, w listopadzie 2026 projekt jest w wersji 0.22 - przed 1.0 API i konfiguracja mogą się jeszcze zmieniać.
// tests/checkout.e2e.ts
import { test, expect } from 'e2e';
test('klient przechodzi na plan Pro', async ({ app, agent, screen }) => {
await app.open('/settings/billing');
await agent.act('upgrade the workspace to the Pro plan');
await agent.assert('the invoice preview shows a prorated amount');
await expect(screen.getByRole('status')).toContainText('Pro');
});
Jaki problem rozwiązuje
Klasyczne testy E2E są kruche. Ktoś zmieni nazwę przycisku, przebuduje formularz albo doda baner z cookies i test pada, choć aplikacja działa. Ktoś musi go poprawić, a przy kilkuset testach to stały koszt.
Testy prowadzone w całości przez agenta AI mają odwrotny problem. Nie pękają przy zmianie UI, ale każde uruchomienie kosztuje tokeny, wynik bywa różny przy tym samym kodzie i po zielonym teście trudno powiedzieć, co dokładnie zostało sprawdzone.
e2e pozwala dla każdego kroku wybrać osobno, czy ma być deterministyczny, czy agentowy, a kroki agentowe po pierwszym udanym przejściu nagrywa i odtwarza bez modelu. Dzięki temu testy są tanie i powtarzalne, dopóki aplikacja się nie zmieni.
Trzy rodzaje kroków
| Krok | API | Czy woła model |
|---|---|---|
| Cel | agent.act('...') |
tak, chyba że krok odtwarza się z cache |
| Asercja agentowa |
agent.assert, agent.waitFor, agent.extract
|
tak, zawsze |
| Lokator |
screen.getBy... + expect(...)
|
nie |
agent.act dostaje jeden cel, np. “dodaj do koszyka najtańszy produkt”. Agent sam decyduje, co kliknąć. Model widzi drzewo dostępności strony (accessibility tree) i screenshoty.
Test bez żadnego kroku agentowego w ogóle nie potrzebuje modelu - wtedy e2e działa jak zwykły runner na Playwright.
Replay cache i self-healing
To jest główny powód, dla którego o e2e tyle się mówi.
- Pierwsze uruchomienie: agent wykonuje krok
agent.act, a runner zapisuje jego akcje (w co kliknął, co wpisał). - Nagranie trafia do cache dopiero wtedy, gdy przejdzie późniejsza asercja - lokator z
expectalboagent.assert. Krok niczym niezweryfikowany nie zostaje zapisany. - Kolejne uruchomienia odtwarzają nagranie bez wywołania modelu, z prędkością zwykłego skryptu.
- Gdy UI się zmieni (np. przycisk “Apply” nazywa się teraz “Redeem”), odtwarzanie zatrzymuje się w miejscu, w którym kontrolka przestała pasować. Replay nigdy nie zgaduje “najbliższego podobnego” przycisku.
- Agent przejmuje krok od aktualnego ekranu. Dostaje listę akcji już wykonanych, więc nie powtórzy np. wysłania formularza.
- Jeśli asercja po kroku przejdzie, zapisuje się nowe nagranie. Następne uruchomienie znowu idzie bez modelu.
Nagrania to pliki JSON w .e2e/cache/. Lokalnie cache działa w trybie read-write, w CI domyślnie read-only. Podsumowanie po przebiegu pokazuje, ile kroków poszło z cache, ile przejął agent i ile tokenów zużyto:
AI 4.1k tokens · 2 model calls
Cache 4 replayed · 1 handed off · 1 missed
Nagrania zawierają wpisane wartości (poza sekretami) i odtwarzają się z uprawnieniami testu, więc jeśli trafiają do repozytorium, przeglądaj je jak kod testów.
Instalacja i pierwszy test
Wymagania: Node.js 24.8+ (albo 22.22.3+), na Windows WSL. Do testów mobilnych Xcode z symulatorem iOS albo Android SDK z emulatorem.
npx e2e init # kreator: web albo mobile, wybór modelu, przykładowy test
npx e2e run # uruchomienie testów
npx e2e doctor # diagnostyka środowiska (przydatne przy mobile)
Przykładowa konfiguracja dla aplikacji webowej z modelem Claude:
// e2e.config.ts
import type { E2EConfig } from 'e2e';
import { web } from '@e2e-dev/web';
import { anthropic } from '@ai-sdk/anthropic';
export default {
targets: [{ engine: web(), app: { url: 'http://localhost:3000' } }],
agents: { default: { model: anthropic('claude-sonnet-5-5') } },
} satisfies E2EConfig;
Model jest dowolny: każdy dostawca z AI SDK (Anthropic, OpenAI, OpenRouter, Vercel AI Gateway), model lokalny przez serwer kompatybilny z OpenAI (np. Ollama) albo subskrypcja, za którą już płacisz (npx e2e login openai, npx e2e login github-copilot). Pakiet @e2e-dev/acp pozwala wykonywać kroki agenta na Claude Code albo Codex. Model musi obsługiwać wywołania narzędzi i obrazy.
Najszybsza droga w istniejącym projekcie: wklej do Claude Code prompt startowy z quickstartu. Agent sam odpali init, skonfiguruje adres aplikacji, uruchomi przykład i napisze pierwszy test głównej ścieżki.
Jak pisać dobre testy
- Jeden
agent.act= jeden cel, a po nimexpect. Zamiast “otwórz plan Pro, ustaw 3 miejsca i zapłać” - trzy osobne kroki, każdy ze sprawdzeniem. Błąd od razu pokazuje, który cel się nie udał, a każdy krok ma osobne nagranie w cache. - Pisz cele słowami, które są na ekranie.
- Dane testowe podawaj w
params:agent.act('invite {email} as an editor', { params: { email } }). - Wartości zmienne między przebiegami (adres e-mail z datą) opakuj w
unique(), inaczej cache nie odtworzy kroku. - Rzeczy krytyczne (kwota na fakturze, status zamówienia) sprawdzaj lokatorem, nie
agent.assert. Asercja agentowa zawsze woła model, więc jest wolniejsza, kosztuje i nie jest w pełni deterministyczna. - Nie dodawaj
sleep- lokatory i akcje same czekają.
Logowanie robi się raz w teście test.setup, który zapisuje nazwaną sesję, a pozostałe testy ją odtwarzają. Hasła są deklarowane w konfiguracji jako credentials i trafiają do testu jako obiekt Secret - model widzi tylko nazwę <secret:admin.password>, a wartość wpisuje sam runner.
Pozostałe możliwości
e2e explore - eksploracja bez pisania testu. Podajesz cel, agent sam przechodzi aplikację i zgłasza znaleziska z krokami do odtworzenia i screenshotami:
npx e2e explore 'Przejdź checkout jak nowy klient i zgłoś wszystko, co działa źle' --headed
npx e2e explore 'Sprawdź stronę cennika na szerokości desktop, tablet i telefon'
Znalezisko typu issue kończy przebieg kodem 1, warning nie. To dobre narzędzie do szybkiego przeglądu przed wydaniem, ale każde znalezisko trzeba zweryfikować - agent też się myli.
Mobile - ten sam styl testów dla iOS i Androida (@e2e-dev/mobile), na lokalnym symulatorze albo na urządzeniach z BrowserStack, TestMu (dawniej LambdaTest), Limrun czy Expo. Jedno API dla webu i obu platform mobilnych to rzadkość wśród takich narzędzi.
Integracja z agentami kodującymi - init instaluje skill dla Claude Code, Codex i Cursora oraz serwer MCP (e2e mcp), przez który agent pracuje na żywej aplikacji, sprawdza lokatory przed zapisaniem testu i weryfikuje własne zmiany w UI. Cała dokumentacja jest w paczce, w node_modules/e2e/docs.
CI - npx e2e run --reporter list,junit na dowolnym CI z Node. Raporty, screenshoty i trace są w katalogu .e2e/, który warto wgrywać jako artefakt także przy porażce. Pakiet @e2e-dev/github publikuje wyniki jako komentarz w PR-ze.
Porównanie z innymi narzędziami
Stan na listopad 2026. Narzędzia z AI zmieniają się co kilka tygodni, więc przed wyborem sprawdź aktualną dokumentację.
Narzędzia z AI
| Narzędzie | Jak się pisze testy | Rola AI w czasie testu | Przebieg bez modelu / naprawa przy zmianie UI | Platformy | Licencja i koszt |
|---|---|---|---|---|---|
| e2e (TesterArmy) | TypeScript: lokatory + kroki agent.act zdaniem |
wykonuje cele i asercje agentowe | tak - nagrania zweryfikowane asercją, agent przejmuje krok i zapisuje nowe nagranie | web, iOS, Android | Apache-2.0, płacisz tylko za model (także lokalny albo subskrypcja) |
| Stagehand (Browserbase) | TypeScript/Python: act, extract, observe na Playwright |
wykonuje akcje i wyciąga dane | cache akcji | web | MIT, model + opcjonalnie chmura przeglądarek. Bardziej do automatyzacji i scrapingu niż do testów - brak własnego runnera testów |
| Midscene.js (ByteDance) | JavaScript albo YAML, polecenia zdaniem | rozpoznaje ekran obrazem (vision) | cache planowania kroków | web, Android, iOS | MIT, płacisz za model z obsługą obrazów |
| Agenci Playwrighta (planner, generator, healer) | AI pisze zwykłe testy Playwrighta i naprawia te, które padły | brak - AI działa tylko przy pisaniu i naprawie | test w CI to zwykły kod, naprawę robi healer na żądanie | web | Apache-2.0, model tylko w czasie developmentu |
| Maestro | YAML (flows), deterministyczne kroki | eksperymentalne assertWithAI, serwer MCP dla agentów |
nie dotyczy - kroki są deterministyczne | iOS, Android, web | CLI open source, chmura płatna |
| Momentic | edytor low-code, kroki i asercje zdaniem | wykonuje kroki, auto-heal lokatorów | tak - poprawka do akceptacji przez człowieka | web, mobile | komercyjny SaaS |
| testRigor | testy pisane po angielsku, bez kodu | interpretuje każdy krok | tak, opiera się na tym, co widać na ekranie, a nie na selektorach | web, mobile, desktop | komercyjny SaaS, drogi przy pełnym pakiecie |
| QA Wolf, usługa hostowana TesterArmy | testy pisze i utrzymuje dostawca | zależnie od dostawcy | po stronie dostawcy | web, mobile | usługa płatna miesięcznie albo za liczbę testów |
Co wyróżnia e2e na tym tle: połączenie otwartego kodu, pełnego runnera testów, jednego API dla webu i mobile oraz cache, który zapisuje tylko kroki potwierdzone asercją. Inne narzędzia mają pojedyncze z tych cech, rzadko wszystkie naraz.
Narzędzia klasyczne
| Narzędzie | Jak się pisze testy | Platformy | Mocne strony | Słabe strony |
|---|---|---|---|---|
| Selenium / WebDriver | kod w niemal każdym języku | web (wszystkie przeglądarki) | standard od lat, ogromna baza wiedzy, Selenium Grid | wolniejszy, ręczne czekanie, kruche selektory |
| Cypress | JavaScript, test działa w przeglądarce | web | wygodne debugowanie, podgląd krok po kroku | jedna karta, ograniczenia przy wielu domenach i iframe’ach |
| Playwright | TS/JS, Python, Java, .NET | Chromium, Firefox, WebKit | szybki, sam czeka na elementy, trace viewer, równoległe przebiegi | selektory nadal trzeba utrzymywać |
| Testy systemowe frameworka (Capybara w Rails, testy Django, Laravel Dusk) | kod w języku aplikacji | web | dostęp do fixtures i bazy, uruchamiane razem z resztą testów | tylko własna aplikacja, nie do testów na produkcji |
| Cucumber / Gherkin (BDD) | scenariusze zdaniami Given/When/Then
|
web, mobile (przez Selenium/Appium) | czytelne dla osób spoza IT | każde zdanie trzeba zaimplementować kodem - to tylko warstwa opisu, nie AI |
| Appium | WebDriver dla aplikacji mobilnych | iOS, Android | jeden kod dla obu platform, dowolny język | wolny, skomplikowana konfiguracja, niestabilny |
| Detox | JavaScript | React Native (iOS, Android) | synchronizacja z aplikacją, mało niestabilnych testów | tylko React Native |
| XCUITest / Espresso | Swift / Kotlin, natywnie | osobno iOS i Android | najszybsze i najstabilniejsze na swojej platformie | dwa osobne zestawy testów |
Jak wybrać
- Testy własnej aplikacji uruchamiane przy każdym commicie: dalej Playwright albo testy systemowe frameworka. Są szybkie, darmowe i deterministyczne. Agenci Playwrighta mogą pomóc je pisać i naprawiać.
- Ścieżki przez cudze UI, testy na produkcji, częste zmiany wyglądu: e2e albo Midscene.js.
- Aplikacje mobilne: Maestro, jeśli wystarczą deterministyczne kroki. e2e albo Midscene.js, jeśli chcecie kroki agentowe i ten sam styl dla webu.
- Automatyzacja przeglądarki i pobieranie danych, a nie testy: Stagehand.
- Brak programistów do utrzymania testów: usługa hostowana (Momentic, testRigor, QA Wolf, TesterArmy).
Jak używać e2e w firmie robiącej oprogramowanie
e2e nie zastępuje testów jednostkowych ani integracyjnych. Jeśli macie działające testy systemowe w swoim frameworku (Rails, Django, Playwright), nie przepisujcie ich - stracicie fixtures i setup bazy, a zyskacie drugi stos technologiczny. e2e opłaca się tam, gdzie klasyczne testy są drogie albo ich nie ma.
Gdzie ma największy sens
-
Ścieżki przez cudze UI. Instalacja integracji z marketplace, płatność przez bramkę, logowanie OAuth u zewnętrznego dostawcy, portale państwowe. Tego UI nie kontrolujecie i zmienia się bez ostrzeżenia. Krok
agent.actprzeżyje zmianę, a wasze asercje dalej sprawdzają wynik po waszej stronie. - Testy na produkcji po deployu i z crona (smoke testy, monitoring syntetyczny). Dzięki cache codzienny przebieg prawie nie zużywa tokenów, dopóki nic się nie zmieni.
- Aplikacje mobilne. Jeden test dla iOS i Androida zamiast osobnych w XCUITest i Espresso.
-
Pętla weryfikacji dla agentów AI. Agent zrobił zmianę w kodzie, sam przeklikał aplikację przez
e2e mcpi zostawił po sobie test regresyjny. Przy dużej ilości kodu pisanego przez agentów to realna oszczędność czasu przy review. -
Przegląd przed wydaniem -
e2e explorena środowisku testowym z celem “sprawdź nowy moduł X, także na szerokości telefonu”. Wychwytuje rozjechane układy, literówki i oczywiste błędy, których test jednostkowy nie zobaczy.
Jak wprowadzić to w zespole
- Zacznijcie od
e2e explorena środowisku testowym albo preview PR-a. Bez pisania testów i bez zmian w repozytorium. Po godzinie wiadomo, czy znaleziska są wartościowe. - Wybierzcie jedną kruchą ścieżkę, która często psuje istniejące testy, i napiszcie ją w e2e. Porównajcie po miesiącu: ile razy test wymagał ręcznej poprawki, ile kosztowały tokeny.
- Trzymajcie testy e2e w osobnym katalogu albo repozytorium z własnym
package.json. Projekt wydaje nowe wersje co kilka dni - łatwiej kontrolować aktualizacje, gdy nie są wymieszane z zależnościami aplikacji. - W CI zostawcie domyślny tryb cache
read-only, a nagrania odświeżajcie lokalnie albo w osobnym, zaufanym jobie.
Bezpieczeństwo i dane
- Model dostaje screenshoty i treść strony. Uruchamiaj testy wyłącznie na kontach i danych testowych, nigdy na danych prawdziwych klientów.
- Hasła i tokeny tylko jako
Secret. Redakcja działa na tekście - jeśli aplikacja wyświetli sekret w zwykłym polu, będzie widoczny na screenshocie wysłanym do modelu. Nagrania wideo niczego nie maskują. - Klucz API do modelu dawaj tylko jobom z zaufanych branchy. Kod z PR-a z forka uruchamiaj bez sekretów.
- CLI domyślnie wysyła anonimową telemetrię (bez treści testów). Wyłączenie:
E2E_TELEMETRY_DISABLED=1albonpx e2e telemetry disable. - Ustawcie limit wydatków u dostawcy modelu.
Ograniczenia
- Wersja 0.x, API się zmienia. Przy aktualizacji czytajcie changelog.
-
agent.assertzawsze woła model. Test złożony głównie z asercji agentowych będzie wolny, płatny przy każdym przebiegu i czasem niestabilny. - Brak niezależnych benchmarków - większość materiałów o skuteczności pochodzi od autorów i z postów premierowych.
- Testy mobilne w CI wymagają maszyny z macOS dla iOS i Linuksa z KVM dla Androida, albo płatnego dostawcy urządzeń.
Zastosowania w firmach, które nie robią oprogramowania
e2e to narzędzie dla programistów (terminal, Node.js, pliki konfiguracyjne). Firma bez działu IT potrzebuje kogoś technicznego do ustawienia go raz, a potem może korzystać z gotowych testów i raportów. Kilka sytuacji, w których to się opłaca:
Sklep internetowy. Codzienny test, który wchodzi na sklep, wyszukuje produkt, dodaje go do koszyka i dochodzi do płatności w trybie testowym bramki. Po aktualizacji wtyczki, motywu czy samej platformy (WooCommerce, Shopify, PrestaShop) od razu wiadomo, że koszyk przestał działać - a nie dopiero wtedy, gdy klienci przestaną kupować. Kroki agentowe dobrze znoszą zmiany wyglądu sklepu.
Firma usługowa z formularzami. Formularz kontaktowy, rezerwacja wizyty, zapis na szkolenie. Test sprawdza, czy formularz się wysyła i czy pojawia się potwierdzenie. Psujący się po cichu formularz to dla wielu firm najczęstsza utrata leadów.
Agencja marketingowa. Przed startem kampanii e2e explore na landing page’u klienta: czy formularz działa, czy strona nie rozjeżdża się na telefonie, czy nie ma literówek i niedziałających linków. Raport ze screenshotami można przekazać klientowi.
Firma zamawiająca aplikację u software house’u. Odbiór aplikacji webowej albo mobilnej: własny zestaw testów najważniejszych ścieżek zapisany językiem naturalnym (“zarejestruj nowego klienta”, “złóż zamówienie na 3 sztuki”). Każda nowa wersja od wykonawcy przechodzi ten sam zestaw, bez polegania wyłącznie na jego testach.
Firma korzystająca z wielu systemów webowych (CRM, ERP, panel kuriera, bankowość firmowa w wersji testowej). Po aktualizacji systemu przez dostawcę test sprawdza, czy kluczowe czynności nadal da się wykonać, np. czy eksport raportu działa.
Dwie uwagi:
- e2e jest narzędziem do testowania, a nie do automatyzacji pracy. Do codziennego przeklepywania danych między systemami lepiej nadają się platformy automatyzacji i integracje przez API - patrz AI do automatyzacji.
- Testy na produkcji muszą używać trybu testowego płatności i kont testowych. Test, który składa prawdziwe zamówienie albo wysyła maile do klientów, narobi więcej szkody niż pożytku. Automatyczne klikanie po cudzych serwisach sprawdź też z regulaminem dostawcy.
Firmy, które nie chcą utrzymywać niczego same, mogą skorzystać z płatnej usługi hostowanej tego samego producenta (TesterArmy) albo z podobnych usług QA - wtedy testy opisuje się w przeglądarce, a infrastrukturą zajmuje się dostawca.
Źródła
- Repozytorium tester-army/e2e
- Dokumentacja e2e - szczególnie: Core concepts, Caching, Self-healing tests, Security
- Ogłoszenie premiery (DEV Community)
- Launch HN: TesterArmy (dyskusja o usłudze hostowanej)
- Expo - przewodnik użycia e2e
- Maestro - assertWithAI
- Momentic - auto-heal
- Midscene.js vs Playwright
- Stagehand vs Browser Use vs Playwright