[Intum Dev](https://intum.dev/index.md) / [Narzędzia AI](https://intum.dev/narzedzia-ai.md)

# [e2e (TesterArmy) - testy end-to-end z agentem AI dla web i mobile](https://intum.dev/narzedzia-ai/e2e-testy-end-to-end-z-agentem-ai.md)

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](https://github.com/tester-army/e2e), dokumentacja na [e2e.com/docs](https://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ć.

```ts
// 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.

1. Pierwsze uruchomienie: agent wykonuje krok `agent.act`, a runner zapisuje jego akcje (w co kliknął, co wpisał).
2. Nagranie trafia do cache dopiero wtedy, gdy przejdzie **późniejsza asercja** - lokator z `expect` albo `agent.assert`. Krok niczym niezweryfikowany nie zostaje zapisany.
3. Kolejne uruchomienia odtwarzają nagranie bez wywołania modelu, z prędkością zwykłego skryptu.
4. 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.
5. Agent przejmuje krok od aktualnego ekranu. Dostaje listę akcji już wykonanych, więc nie powtórzy np. wysłania formularza.
6. 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:

```text
           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.

```bash
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:

```ts
// 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](https://e2e.com/docs/quickstart). 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 nim `expect`. 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:

```bash
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.act` przeż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 mcp` i 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 explore` na ś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

1. Zacznijcie od `e2e explore` na środowisku testowym albo preview PR-a. Bez pisania testów i bez zmian w repozytorium. Po godzinie wiadomo, czy znaleziska są wartościowe.
2. 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.
3. 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.
4. 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=1` albo `npx e2e telemetry disable`.
- Ustawcie limit wydatków u dostawcy modelu.

### Ograniczenia

- Wersja 0.x, API się zmienia. Przy aktualizacji czytajcie changelog.
- `agent.assert` zawsze 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](../narzedzia-ai/ai-do-automatyzacji-zapier-make-n8n-i-platformy-workflow).
- 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](https://github.com/tester-army/e2e)
- [Dokumentacja e2e](https://e2e.com/docs) - szczególnie: Core concepts, Caching, Self-healing tests, Security
- [Ogłoszenie premiery (DEV Community)](https://dev.to/testerarmy/introducing-e2e-open-source-agentic-testing-for-web-ios-and-android-4flb)
- [Launch HN: TesterArmy (dyskusja o usłudze hostowanej)](https://news.ycombinator.com/item?id=48586299)
- [Expo - przewodnik użycia e2e](https://docs.expo.dev/guides/using-e2e/)
- [Maestro - assertWithAI](https://docs.maestro.dev/api-reference/commands/assertwithai)
- [Momentic - auto-heal](https://momentic.ai/docs/reliability/auto-heal.md)
- [Midscene.js vs Playwright](https://aicoolies.com/comparisons/midscene-js-vs-playwright)
- [Stagehand vs Browser Use vs Playwright](https://www.nxcode.io/resources/news/stagehand-vs-browser-use-vs-playwright-ai-browser-automation-2026)


---

## Powiązane

- [Chrome DevTools MCP — debugowanie przeglądarki przez AI](https://intum.dev/narzedzia-ai/chrome-devtools-mcp-debugowanie-przegladarki-przez-ai.md)
- [Krajobraz narzędzi AI — przewodnik po kategoriach i porównaniach](https://intum.dev/narzedzia-ai/krajobraz-narzedzi-ai-przewodnik-po-kategoriach-i-porownaniach.md)
- [Agenci CLI do kodowania — Claude Code, Codex, Gemini CLI, OpenCode i Aider w porównaniu](https://intum.dev/narzedzia-ai/agenty-cli-do-kodowania-claude-code-codex-gemini-cli-i-copilot-w-porownaniu.md)