Polityka E2E — wymagane + agent uruchamia browser test przed merge

Pytanie ze scorecardu: Jaki jest wymóg E2E dla zmian UI? Odpowiedź na maks (3 pkt): E2E wymagane + agent uruchamia browser test sam przed merge.

Dlaczego to ważne w 2026 (klasa defektów: AI psuje UI)

Testy jednostkowe weryfikują kod. Type check weryfikuje kod. Linter weryfikuje kod. Żaden z nich nie weryfikuje feature’a. Tylko prawdziwa przeglądarka, sterująca prawdziwą stroną, na prawdziwym przepływie użytkownika, powie Ci, czy to, czego dotyka klient, dalej działa. W 2026 ta luka to już nie niuans — to dominująca klasa defektów w PR‑ach pisanych przez AI.

Wzorzec jest dziś dobrze udokumentowany w zespołach, które przez rok agentowego developmentu logowały post‑merge regressions: diff wygląda sensownie, unit testy są zielone, type checker zielony, code review LGTM — i potem user klika przycisk, a nic się nie dzieje, bo agent zmienił data-testid, zgubił onClick przy refaktorze wrappera, zamienił <a> na <button> bez href, albo przesunął modal za stacking context, który teraz siedzi pod cookie banerem. Kod “wygląda dobrze”. UI jest rozjebany. To jest klasa defektów “AI psuje UI” — i to jest pojedynczy największy powód, dla którego zespoły, które wdrożyły Cursora, Claude Code czy Codex w 2024–2025, najpierw zobaczyły wzrost post‑merge incident rate, zanim zobaczyły spadek.

Powód jest strukturalny. LLM, który pisze kod, umie czytać kod. Domyślnie nie widzi wyrenderowanej strony. Nie wie, że nowy flexbox sprawił, że submit nakłada się na privacy notice na mobile, że nowa state machine zostawiła dialog otwarty po drugim kliknięciu, ani że kształt odpowiedzi API pasuje do fixture’a w stagingu, ale nie do prawdziwego /me na produkcji. Jedyny check, który zna którąkolwiek z tych rzeczy, to ten, gdzie przeglądarka faktycznie renderuje stronę, a drugi agent (albo test harness, albo oba) weryfikuje wyrenderowany rezultat.

W 2026 poprzeczka przesunęła się dwa razy ponad “mamy E2E, ale tylko QA odpala je w nocy” (odpowiedź na 1 punkt z 2024): najpierw do “E2E jada na każdym PR w CI” (2 punkty), potem do “agent, który napisał PR, sam puszcza browser checks przed prośbą o review” (3 punkty). Mniej niż to i płacisz za prędkość AI‑authorship — czyszczeniem, incident response i utratą zaufania. Jeśli zdobyłeś 0 lub 1 — sygnał widać po incydentach: front‑end regressions nieproporcjonalnie pochodzą z PR‑ów dotykających UI bez pokrycia E2E na zmienionym flow, a reakcja brzmi “dodamy test” zamiast “agent powinien był to złapać przed otwarciem PR”.

Co tak naprawdę znaczy “maks punktów”

Każdy PR dotykający UI uruchamia E2E w CI jako wymagany check. GitHub branch protection ma na liście co najmniej jeden suite Playwrighta (albo Cypressa) jako required. PR‑a nie da się zmergować, jeśli check jest czerwony. Żadnych “domergujemy i przepuścimy później”.
Agent sam uruchamia browser checks przed otwarciem PR. Wewnątrz sesji IDE/CLI, która napisała zmianę, agent steruje prawdziwą przeglądarką przez Playwright MCP, chrome‑devtools MCP albo browser‑use, asercjuje istotne flowy, robi screenshoty, a dopiero potem commituje i pushuje. Failures zostają w pętli agenta, nie w Twojej kolejce review.
Testy asercjują zachowanie i dostępność, nie selektory. Playwright getByRole / getByLabel (albo ekwiwalent w Cypressie) sprawiają, że test wciąż przechodzi, kiedy agent zmienia nazwę klasy — a fail‑uje, gdy agent w ogóle wyrzuca accessible name. Testy żyją blisko intencji (“user może dokończyć checkout”), nie markupu.
Visual regression pokrywa powierzchnie, gdzie piksele mają znaczenie. Chromatic, Percy, Argos albo natywne toHaveScreenshot z Playwrighta wpięte w ten sam check PR, z reviewerami zatwierdzającymi visual diffy jawnie. Agent dostaje informację, które powierzchnie są visual‑critical (pricing, checkout, dashboard chrome), i robi re‑shoot baseline’ów przy intencjonalnych zmianach.
Budżet flake’a wymuszony i widoczny. Flaky testy mają ownera, deadline i retry policy ograniczone do jednej‑dwóch prób. Test, który leci na zmianę więcej niż dwa razy w tygodniu, auto‑trafia do kwarantanny i otrzymuje ticket — nie gnije po cichu w suite, niszcząc zaufanie do czerwieni.
Agent ma skill do browser test. Plik tests/e2e/CLAUDE.md (albo ekwiwalent dla Cursora i Codexa) mówi agentowi, który suite uruchamiać, jak go odpalać headed vs headless, jak zalogować test usera i które powierzchnie wymagają visual diffów. Agent nie wymyśla wiring od nowa co sesję.
Pre‑merge logi są częścią PR. Agent dołącza output swojego browser run — screenshoty, trace’y, logi sieciowe — do treści PR, więc reviewer nie musi nic odpalać, żeby wiedzieć, co się stało.

Konkretnie: developer prosi agenta o zmianę copy w formularzu rejestracji. Agent edytuje komponent React, odpala npm test, odpala npx playwright test signup.spec.ts przeciw lokalnemu dev serwerowi, patrzy, jak suite świeci zielonym (ze screenshotem efektu w PR), a dopiero potem otwiera pull request. Wymagany check PR odpala ten sam suite w CI przeciw preview deploymentowi, plus Chromatic flaguje diff copy do one‑click visual approval. Łączny czas po stronie agenta: 90 sekund. Łączny czas review po stronie człowieka: 60 sekund.

Aktualny krajobraz (zweryfikowany web‑searchem)

Playwright MCP + integracja agenta

Microsoft wypuścił Playwright MCP na początku 2025 — MCP serwer, który podaje live’ową sesję Playwrighta dowolnemu MCP‑kompatybilnemu agentowi (Claude Code, Cursor, Codex CLI, GitHub Copilot Workspace). Zamiast odpalać preskryptowane scenariusze, agent dostaje intencję — “dokończ flow rejestracji i zweryfikuj welcome modal” — inspectuje accessibility tree i dispatchuje akcje Playwrighta (click, fill, expect) po ARIA roles, nie po CSS selectorach. Na początku 2026 to stało się domyślnym sposobem bootstrapowania 70–80% nowego pokrycia E2E. Ten sam MCP używany jest w dwóch trybach: na autorshipie (agent pisze test) i na weryfikacji (agent uruchamia istniejący suite przed PR). Killer property: intencja jest stabilna ponad rewritami UI — kiedy agent przesypuje markup, accessibility tree wciąż kotwiczy test.

chrome‑devtools MCP

Google’owe chrome‑devtools MCP wystawia Chrome DevTools Protocol — performance traces, audyty Lighthouse, network inspection, błędy konsoli, detekcję layout shift — tym samym agentom. Gdzie Playwright MCP służy do sterowania przeglądarką, chrome‑devtools MCP służy do jej obserwowania. Razem odpowiadają na pytania, na które samo funkcjonalne E2E nie odpowie: czy ten PR dodał layout shift? czy zregresował LCP na pricingu? czy konsola sypie teraz CSP violations? W 2026 kanoniczny setup to oba MCP równolegle, z agentem odpalającym chrome‑devtools po runu Playwrighta na PR‑ach dotykających krytycznej strony.

Cypress + GitHub Actions

Cypress został dominującym wyborem dla zespołów, które wdrożyły E2E przed 2024. W 2026 Cypress wypuścił cypress.io/ai oraz integrację z GitHub Actions w analogicznym wzorcu co Playwright: agenci generują speców, odpalają je w CI na każdym PR, paralelizują przez kontenery i postują wyniki jako GitHub Check. Drzewo decyzyjne — zostań przy Cypressie, jeśli masz inwestycję; wybierz Playwright MCP dla ściślejszej integracji agentowej, jeśli zaczynasz od zera.

Narzędzia visual regression (Chromatic, Percy, Argos)

Chromatic (Storybook), Percy (BrowserStack) i Argos (open‑source‑friendly) wszystkie integrują się jako GitHub Checks, które trzaskają na czerwono, gdy UI diff przekracza próg. W 2026 Argos dorobił first‑class wsparcie dla Playwrighta i agentowy workflow, w którym agent sam oznacza diff jako expected (z uzasadnieniem) lub regression. Wzorzec: visual regression jada na każdym PR jako “advisory”, dopóki reviewer (albo senior agent) nie zatwierdzi/odrzuci. Krytyczne powierzchnie (pricing, checkout, signup) promują do required.

Włączanie E2E do bramki PR

Branch protection na default branchu ma E2E job na liście required status checks. PR‑y nie mergują się przy czerwonym; --admin overrides są zarezerwowane dla emergency i audytowane. Kombinacja “agent odpala suite lokalnie przed pushem” + “CI re‑odpala suite na preview deploymencie” + “required check on merge” zamyka pętlę — agent nie zakłada, że CI złapie jego błędy, a CI nie da się ominąć, gdy agent twierdzi, że przetestował lokalnie.

Krok po kroku: wdrożenie agentowego E2E

Wybierz jeden test runner i jeden flow na start. Nie próbuj konwertować całego suite’a. Wybierz pojedynczy najważniejszy flow — signup → first‑run dla SaaS, browse → checkout dla e‑commerce. Wybierz jeden runner: Playwright, jeśli startujesz od zera, Cypress, jeśli masz już inwestycję. Koszt niespójności w 2026 jest większy niż koszt wybrania trochę nie tego narzędzia.
Pierwsze trzy testy napisz z agentem, w trybie pair‑codingu. Otwórz Playwright MCP (albo AI mode w Cypressie) i poproś agenta o wygenerowanie speca. Siedź obok przez pierwsze trzy: agent overfit‑uje do selektorów pierwszy raz, gubi flaky waits drugi, ignoruje accessibility queries trzeci. Przy czwartym zinternalizuje Twoje konwencje.
Kotwicz na rolach i accessible names, nie CSS selectorach. Pojedynczy największy determinator przeżycia suite’a pod AI authorshipem to to, czy testy pytają getByRole('button', { name: 'Sign up' }) zamiast [data-testid="signup-btn"] lub .btn.btn-primary.mt-4. Dodaj regułę lintera, która odrzuca raw CSS selectory w plikach spec. Bonus: wymusza to higienę dostępności — przycisk bez accessible name fail‑uje test i fail‑uje screen reader.
Wepnij suite do CI jako required check. Dodaj workflow odpalający suite na każdym PR przeciw preview deploymentowi albo Docker‑composed lokalnemu stackowi. Paralelizuj między 4–8 shards, żeby total wall‑clock dla 200‑specowego suite’a został pod 5 minut. W GitHub branch protection oznacz job jako required zanim suite będzie comprehensive — mały required suite, który zawsze jada, bije duży suite, który jest “advisory”.
Dodaj tests/e2e/CLAUDE.md (i ekwiwalenty), żeby agent znał wiring. Udokumentuj: jak odpalić suite (npm run test:e2e), jak wystartować dev server, jak zalogować test usera, które env vars są wymagane, które powierzchnie wymagają visual diffów, jaka jest flake policy. Powiedz agentowi: “Przed otwarciem PR dotykającego src/components/ lub src/pages/ uruchom npm run test:e2e i dołącz output do treści PR. Jeśli test fail‑uje, napraw przyczynę; nie skipuj testu.” Codex czyta AGENTS.md, Cursor czyta .cursor/rules/, Claude Code czyta CLAUDE.md.
Zainstaluj Playwright MCP i chrome‑devtools MCP dla agenta. Dla Claude Code: claude mcp add playwright --transport http <url>, potem to samo dla chrome‑devtools. Zweryfikuj, że agent umie wylistować MCP tools i sterować sample stroną. Dodaj przykładową sesję do onboardingu — agent otwiera dev server, przechodzi flow, robi screenshot, asercjuje widoczny tekst.
Dodaj visual regression na top trzech stronach. Wepnij Chromatic / Percy / Argos do pricingu, signupu i dashboard chrome. Zacznij z permisywnym progiem i checkiem jako advisory. Po dwóch tygodniach zacieśnij progi i promuj check do required. Powiedz agentowi, które strony są visual‑critical, żeby re‑shootował baseline’y na intencjonalnych zmianach (i nie na incydentalnych).
Postaw flake registry i ownera. Załóż tests/e2e/QUARANTINE.md listujący każdego skwarantannowanego speca, jego failure mode, przypisanego inżyniera i deadline. Owner to jedna nazwana osoba, rotacja kwartalna. Wszystko, co jest w kwarantannie dłużej niż dwa tygodnie, zostaje usunięte albo naprawione. Trzeciej opcji nie ma.
Mierz agent‑side run rate i pre‑merge catch rate. Dwie metryki: (1) procent PR‑ów dotykających UI z evidence, że agent odpalił suite przed pushem, i (2) procent E2E failures w lokalnym runie agenta vs w CI vs na produkcji. Cel: >80% agent‑side evidence, >70% catches przed pushem, <5% na produkcję. Wystaw na Q22 · Panel metryk AI.
Iteruj skill agenta kwartalnie. Przejrzyj failure modes i zaktualizuj tests/e2e/CLAUDE.md lekcjami. Nowy flaky pattern? Dodaj helper. Nowa visual‑critical powierzchnia? Dodaj do listy. Skill compounduje się — każda zbankowana lekcja oznacza, że następna sesja płaci niższy podatek.

Częste pułapki

Flaky testy traktowane jako wina testu. Spec, który losowo time‑outuje, prawie nigdy nie jest “wina testu”; to nieobsłużony race, brakujący wait‑for, animacja, która nigdy nie wygasa, albo backend zwracający 200 z pustym ciałem. Kwarantanna to holding pattern, nie fix. Zbadaj w ciągu dwóch tygodni albo skasuj speca — pozwalanie flake’om gnić uczy zespół ignorowania czerwonego CI, co niszczy bramkę.
Skipowanie E2E dla “małych zmian UI”. Najbardziej regression‑prone PR‑y w erze AI to te, które agent ocenia “małe”: copy tweak, który zepsuł query po etykiecie, CSS refactor, który przesunął przycisk za inny element, “drobny” prop rename, którego type checker nie złapał, bo konsument używał any. Bramka jest bezwarunkowa na ścieżkach UI. Agent nie głosuje, czy zmiana UI jest na tyle mała, żeby ją pominąć.
Brak headless config / “works on my machine”. Agent przechodzi lokalnie, bo Chrome jest otwarty na 2560×1440 z ciastkami usera; CI fail‑uje, bo headless instance to 1280×720 bez auth. Przypnij viewport, odpalaj headed i headless lokalnie, dziel fixture między tryby, default‑uj agenta na headless.
Testy oparte na selektorach, które pierwszy refactor agenta zepsuje. Jeśli Twój suite pyta .css-1abc2de albo [data-testid="x"], a agent przepisuje wrapper component, połowa suite’a leci na czerwono przez noc — i agent “naprawi” testy, aktualizując selektory zamiast zachować user‑visible kontrakt. Skonwertuj na role i accessible names zanim spuścisz agenta ze smyczy.
Jeden ogromny test, który robi wszystko, albo brak budżetu retry. Monolityczne speci (login → onboarding → tworzenie → zapraszanie → upload → billing) compounduje flake: 1% per krok robi się 6% suite failure rate. Podziel na jednego speca per cel usera. Przypnij retry do jednego w CI i zera lokalnie — pięć retry chowa prawdziwą flakę, zero karze legitymne transient failures.
Agent nic nie odpala lokalnie i po prostu otwiera PR. Bez jawnej instrukcji agenci skipują kosztowne narzędzia. Fix to skill (krok 5) plus pre‑push hook, który odpala npm run test:e2e:fast (smoke subset) na każdej zmianie pod src/components/ lub src/pages/.
Visual regression ustawiony na “advisory na zawsze”. Check, który istnieje, ale nigdy nie blokuje, uczy zespół, żeby go ignorować. Gdy Twoje trzy krytyczne powierzchnie się ustabilizują, promuj check do required. Reviewerzy będą jęczeć tydzień i się przyzwyczają.
CI parallelization, która łamie izolację testów. Odpalanie 8 shards przeciw jednej współdzielonej bazie sprawia, że testy nadeptują sobie nawzajem na stan. Dowieź per‑shard bazy (Docker compose, ephemeral SQLite, neon/supabase branching) albo odpalaj sharded suite’y przeciw in‑memory backendowi.

Jak zweryfikować, że jesteś na miejscu

Losowa próbka PR‑ów dotykających UI z ostatnich 30 dni: >80% zawiera evidence (screenshot, trace, log), że agent odpalił suite przed pushem.
Branch protection na default branchu ma co najmniej jeden job Playwrighta (albo Cypressa) i jeden visual‑regression job na liście required status checks.
Ostatnie 90 dni produkcyjnych incydentów front‑endu: <5% trace‑uje do defektu, który złapałby spec E2E pokrywający rozjebany flow.
Agent w świeżej sesji opisuje obowiązek E2E w jednym zdaniu: “Przed otwarciem PR pod src/components/ lub src/pages/ uruchom npm run test:e2e, dołącz output do treści PR, pushuj tylko przy zielonym.”
tests/e2e/QUARANTINE.md ma zero wpisów albo każdy wpis ma ownera i deadline mniej niż dwa tygodnie naprzód.
Treść najnowszego PR UI autorstwa agenta zawiera screenshoty z lokalnego runa i link do reportu CI Playwrighta.
Nowy inżynier umie odpalić pełen suite E2E lokalnie w mniej niż 10 minut od clone do zielonego — używając wyłącznie tests/e2e/CLAUDE.md i README.
Panel metryk AI (Q22) pokazuje pre‑merge catch rate >70% w trendzie wzrostowym i post‑merge UI incident rate w trendzie spadkowym kwartał‑do‑kwartału.

Dalsza lektura

Q9 · Automatyzacja review PR Warstwowe review (CodeRabbit / Greptile + Claude Code Action / Codex) na bramce E2E.

Q13 · AI w CI/CD Od bramki E2E do pełnego pipeline'u agenta — generate, review, test, deploy z hard gates.

Q17 · Polityka Plan mode Plan mode bramkujący prace UI — design‑time komplement do run‑time bramki E2E.

CTO Scorecard Sprawdź, gdzie stoisz w 25 pytaniach.