Böngészőágensek E2E-teszteléshez: írják az ágensek a Playwright-teszteket, ne futtassák

A böngészőágensek ma már meg tudnak nyitni egy alkalmazást, el tudják olvasni az oldalt, végig tudnak kattintani egy fizetési folyamaton, és meg tudják mondani, hogy működött-e. Csábító ebből tesztkészletet csinálni: hétköznapi nyelven leírni a folyamatokat, és minden pull requestnél egy modellel ellenőriztetni őket. Szerintem ez rossz hely a modellnek. A jobb munkamegosztás: az ágensek végzik a drága emberi munkát – az alkalmazás felderítését, a tesztek megírását és a törött lokátorok javítását –, a CI pedig sima Playwright-teszteket futtat, amelyek minden alkalommal ugyanazt a választ adják.

A cikk összeveti, milyen három módon találkoznak az ágensek az E2E-teszteléssel, végigmegy a Playwright saját tesztágensein, kitér az MCP és a CLI választására kódoló ágenseknél, és rögzíti azokat a korlátokat, amelyekkel elérem, hogy egy önjavító teszt ne „gyógyíthasson el” csendben egy valódi hibát.

Milyen három módon használhatók ágensek E2E-teszteléshez?

A teszt attól hasznos, hogy rögzített orákulum: ugyanaz a kód, ugyanaz az adat és ugyanaz az ellenőrzés ugyanazt az eredményt adja. Egy képernyőképet megítélő modell második vélemény, nem orákulum. Felderítésre hasznos, de a piros buildnek azt kell jelentenie, hogy a termék változott meg, nem azt, hogy a modell gondolta meg magát.

Hogyan működnek a Playwright tesztágensei?

A Playwright három tesztágenst ad ágensdefinícióként, amelyeket az npx playwright init-agents paranccsal teszel a repóba, VS Code-, Claude Code-, Codex- és OpenCode-változattal. A dokumentáció szerint minden Playwright-frissítés után újra kell generálni őket, hogy megkapják az új eszközöket és utasításokat.

• Planner: kap egy kérést, például „tervezd meg a vendégként történő fizetést”, egy seed tesztet, amely előkészíti a fixture-öket és a belépést, és opcionálisan egy követelménydokumentumot. Lefuttatja a seed tesztet, bejárja az alkalmazást, és Markdown tervet ír a specs/ mappába.
• Generator: a tervből Playwright-teszteket készít a tests/ alá, és a forgatókönyvek végrehajtása közben élőben ellenőrzi a szelektorokat és az ellenőrzéseket. A dokumentáció szerint a generált tesztek eleinte hibákat tartalmazhatnak.
• Healer: egy hibás tesztnél újrajátssza a lépéseket, a jelenlegi felületen egyenértékű elemeket keres, javítást javasol, például lokátorfrissítést, várakozás-módosítást vagy adatjavítást, és addig futtatja újra, amíg a teszt át nem megy, vagy a korlátok meg nem állítják. Az eredmény egy sikeres teszt, vagy egy kihagyott, ha úgy ítéli, hogy a funkció hibás.

# Add the agent definitions for your coding agent (regenerate after Playwright upgrades)
npx playwright init-agents --loop=claude

# tests/seed.spec.ts: everything the agents need to reach a logged-in state
import { test, expect } from './fixtures'
test('seed', async ({ page }) => {
  await page.goto('/')
  await expect(page.getByRole('navigation')).toBeVisible()
})

Playwright MCP-t vagy CLI-t használjanak a kódoló ágensek?

A Playwright MCP révén a modell strukturált akadálymentességi pillanatképeken keresztül vezérli a böngészőt képernyőképek helyett, így nem kell hozzá vizuális modell, és elkerüli a pixelekre kattintás kétértelműségét. A saját README-je viszont ma már határt húz: kódoló ágensekhez a skillekkel kiegészített Playwright CLI-t ajánlja, mert a CLI-hívások nem töltenek nagy eszközsémákat és bőbeszédű akadálymentességi fákat a kontextusba. Az MCP azokhoz a ciklusokhoz marad jobb, amelyeknek jót tesz a tartós böngészőmunkamenet, például a felfedező automatizáláshoz és az önjavító tesztekhez.

Ez egybevág az AGENTS.md, skillek, MCP vagy CLI cikk általános mérlegelésével: minden állandóan betöltött eszközséma és minden oldal-pillanatkép minden körben kontextusba kerül. Ha egy tesztmunkamenethez csak néhány oldalolvasás kell, a CLI olcsóbb; a kódoló ágensek tokenspórolása cikk technikái itt is érvényesek.

Miért az akadálymentes markup a szerződés az ágensek és a tesztek között?

A Playwright bevált gyakorlatai a felhasználó által látott tulajdonságokra épülő lokátorokat ajánlják, például getByRole('button', { name: 'Submit' }), CSS-osztályok és XPath helyett, mert a DOM szerkezete gyakrabban változik, mint az, amit a felhasználó lát. A Playwright MCP ugyanezt az akadálymentességi fát olvassa. Ugyanaz a munka, amely képernyőolvasóval használhatóvá teszi az oldalt, az ágensnek is megkönnyíti a felderítést, és újratervezést is túlélő teszteket eredményez. Egy szerep nélküli, formázott div gomb mindhármuk számára láthatatlan.

Az EU-s webshopoknál ez amúgy sem választható; lásd az európai akadálymentességi irányelv B2B-webshopoknak cikket. A szerepek és címkék javítása egyszerre szolgálja a megfelelést, az ágenseket és a tesztek stabilitását.

Hogyan maradnak őszinték az önjavító tesztek?

A healer feladatleírásában benne van a kockázat: addig futtat újra, amíg a teszt át nem megy, és ha úgy véli, hogy a funkció hibás, kihagyottnak jelöli a tesztet. Mindkét kimenet rendben van, ha egy gombot átneveztek. Mindkettő rossz, ha a gomb egy valódi hiba miatt tűnt el. Az én szabályom egyszerű: a healer azt módosíthatja, hogyan talál meg a teszt dolgokat, azt soha, hogy mit ellenőriz.

#!/usr/bin/env bash
# CI gate for agent-made test changes: locator and wait edits pass, assertion edits need review
set -euo pipefail
changed=$(git diff --unified=0 origin/main -- 'tests/**/*.spec.ts' | grep -E '^[-+][^-+]' || true)
if echo "$changed" | grep -Eq 'expect\(|test\.(skip|fixme)\(|\.toHave|\.toBe'; then
  echo "Assertions or skips changed in tests/: needs a human reviewer (label: test-assertions)"
  exit 1
fi

Ugyanez érvényes azokra a tesztekre, amelyeket egy ágens hibajavításhoz ír. Egy regressziós teszt csak akkor ér valamit, ha elbukik, amikor a javítást visszavonják; ezt minden hibajavító PR-nél ellenőrzöm, ahogy az ágensciklus és a hibától a PR-ig tartó munkafolyamatom cikkben leírtam.

Mikor van mégis értelme a futásidejű böngészőágensnek?

Vannak esetek, amikor a rögzített szelektor rossz eszköz. Kiadás előtti felfedező tesztelés, amikor egy ágens szokatlan útvonalakat próbál ki, és jelzi, mi tűnt hibásnak. Füstpróbák olyan külső oldalakon, amelyeket nem te irányítasz, például egy fizetési szolgáltató átirányításán. Hetente változó belső back-office folyamatok. Ezekre az olyan könyvtárak, mint a Stagehand, a természetes nyelvű act, extract és observe hívásokat Playwright-stílusú oldal- és lokátor-API-kkal kombinálják, így egy szkript nagyrészt determinisztikus lehet néhány rugalmas lépéssel. Részletesebben a Stagehand-ismertetőben hasonlítom össze.

Ezeket a futásokat tartsd távol a merge-kaputól. Az eredményeiket issue-ként vagy új determinisztikus tesztként jelentsd, a sikeres vagy sikertelen döntés pedig maradjon olvasható kódnál.

Hogyan néz ki egy gyakorlati beállítás?

1. Egy seed teszt fixture-ökkel a belépéshez és a tesztadatokhoz, hogy az ágensek ismert állapotból induljanak.
2. A specs/ terveit követelményként nézd át: egy rossz terv helyesnek látszó teszteket szül rossz viselkedésre.
3. A generált tesztek csak szerepalapú lokátorokat használnak; a CSS-szelektorok elbuknak a linten.
4. A CI sima npx playwright test-et futtat, hiba esetén trace-szel; a merge-kapuban nincs modell.
5. A healer külön jobként fut, amely PR-t nyit; az ellenőrzések változtatása és a kihagyások átnézésre blokkolva vannak.

Ez a harness engineering a tesztelésre alkalmazva: az ágens irányítókat (seed teszt, tervek, lokátorszabályok) és érzékelőket (tesztfutás, ellenőrzéskapu) kap, az emberi átnézés pedig ott van, ahol a döntések születnek, nem minden soron.

Források

1. Playwright docs: Test agents (planner, generator, healer)
2. Microsoft: Playwright MCP README (MCP vs CLI, accessibility snapshots)
3. Playwright docs: Best practices
4. Playwright docs: Locators
5. Browserbase: Stagehand README (act, extract, observe)