Playwright: egy böngésző-API tesztekhez, szkriptekhez és agentekhez

A Playwright a Microsoft böngésző-automatizálása, mára pedig egy repóban három termék: egy tesztfuttató, egy szkriptelő könyvtár és egy agent-felület MCP-szerverből és parancssori eszközből. Apache-2.0, nincs fizetős kiadása, és továbbra is a kategória legkényelmesebb API-ja. Ennek az értékelésnek az álláspontja: az új end-to-end munka alapértelmezése — és az agent-felületek az oka, hogy a meglévő suite-ot érdemes újranézni.

A Seleniummel, a Cyressszel és a Puppeteerrel versenyez, és egyre inkább a kézzel írt scraping- és QA-szkriptekkel, mert ugyanaz a page objektum szolgálja ki a CI-beli tesztet, az éjszakai riportot és azt az LLM-et, amely accessibility snapshotokon át vezeti a böngészőt. A mag semmilyen része nem igényel modellt: az agent-eszközök ráülnek, és figyelmen kívül hagyhatók — ezért vezetnek be csapatok előbb teszt-eszközként, és csak később fedezik fel az agent-réteget.

Mi ez

A projekt Chromium-, Firefox- és WebKit-automatizálást szállít Windows, Linux és macOS alatt, helyben vagy CI-ben, fej nélkül vagy láthatóan, natív mobil emulációval az Android Chrome-hoz és a Mobile Safarihoz. A jelenlegi sorozat 1.63, 2026 szeptemberében kiadva, a böngésző-binárok pedig ehhez a kiadáshoz vannak rögzítve.

• Apache-2.0 fizetős kiadás nélkül; az npm-csomag Node 20-as vagy újabb verziót ír elő.
• Egy API négy nyelven: JavaScript és TypeScript, Python, Java és .NET.
• Tesztfuttató auto-waitinggel, web-first assertionökkel, fixture-ökkel, párhuzamos projektekkel, shardinggal, újrapróbálással és HTML-jelentéssel.
• A böngészőkontextusok minden tesztnek friss profilt adnak, így a belépési állapot fixture, nem megosztott globális.
• Eszközök a futás köré: codegen, UI mód, trace-nézegető, hálózati mocking, óra-szabályozás és aria snapshotok.
• Kiadásonként hivatalos kontenerképek, amelyek miatt a CI böngészői megegyeznek a helyiekkel.
• Három agent-felület: MCP-szerver, installálható skillökkel rendelkező CLI, valamint planner, generator és healer teszt-agentek.

Hogyan működik

A meghajtó minden böngészővel saját protokollon beszél — patchelt Chromium- és Firefox-buildek, plusz egy patchelt WebKit —, éppen ezért kínálhatja ugyanazt az egy API mindhárom motoron, a legkisebb közös nevező helyett. A lokátorok az akció végrehajtásakor oldódnak fel, minden akció pedig megvárja, hogy az elem működjön; a flaky teszt szokásos javítása így assertion, nem sleep.

A meghajtó felett ül a futtató, ahol az érték java része keletkezik: egy konfigurációs fájl deklarálja a projekteket — böngészők, viewportok, hitelesítések —, a teszteket workerok között osztják el, a sharding gépekre bontja őket, és minden hibához tartozik egy lépésenként visszajátszható trace. Ez a trace teszi lehetővé a támogatott diagnózist is, mert strukturált adat, nem egy stack trace képernyőképe.

Első lépések

Egy scaffold, egy install, egy futás: a npm init playwright@latest megírja a konfigurációt és az első spect, az npx playwright install --with-deps letölti a rögzített böngésző-binárokat a rendszerkönyvtárakkal, a npx playwright test pedig fej nélkül és párhuzamosan fut mindhárom motoron.

import { test, expect, devices } from '@playwright/test';

test('order confirmation shows a number', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByLabel('Email').fill('qa@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('status')).toContainText(/Order WS-\d+/);
});

test.describe('phone', () => {
  test.use({ ...devices['iPhone 15'] });
  test('checkout renders on a phone viewport', async ({ page }) => {
    await page.goto('/checkout');
    await expect(page.getByRole('heading', { name: 'Checkout' })).toBeVisible();
  });
});

Ami gyorsan öregszik, nem a futtató, hanem a szelektorok. A projekt saját tanácsa: szerepcímke- és címkelokátorokat előnyben részesíteni, az assertionöket web-first módon tartani, hogy az időkorlátig újra ellenőrizzenek egyszeri mintavétel helyett, és hibánál trace-et nyitni, nem a stackből következtetni.

Agentek a kormánynál

Ez az a rész, amely megváltoztatta az eszköz szerepét. A Playwright ma szabványos módja annak, hogy egy nyelvi modell böngészőt vezéreljen, a projekt pedig három utat kínál hozzá, mindet első féltől.

# MCP server: structured tool calls, accessibility snapshots with element refs
{
  "mcpServers": {
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
  }
}

# CLI: shell commands for a coding agent, headless by default
npm install -g @playwright/cli
playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli click e5

# Test agents: planner, generator and healer, installed into the repo
npx playwright init-agents --loop=vscode

• Az MCP-szerver accessibility snapshotokat ad vissza: minden elem olyan reft kap, mint az e5, így a modell referenciára kattint, nem koordinátát tippel, és vision modell sem kell. A dokumentáció 70+ eszközt listáz, hálózati mocking, storage, tracing és videó capability flag-ek mögött.
• A CLI a takarékos út: tömör kimenet, állandó daemon, hogy a parancsok ne fizessenek böngészőindítást, igény szerint felfedezett skill-ök és a parancsok között állapotot megőrző munkamenetek.
• A Playwright teszt-agentei — planner, generator és healer — Markdown-teszttervet írnak, abból specet készítenek, a hibás teszteket pedig újrajátszással és az oldal újravizsgálatával javítják; az npx playwright init-agents a VS Code, a Claude Code, a Codex és az OpenCode definícióit telepíti.
• A dokumentáció egyenesen kimondja a cserét: az MCP a specializált agentic hurkokra és a felfedező automatizálásra való, a CLI a nagy kódalapokkal dolgozó coding agentekre, a CLI fej nélkül indul, az MCP pedig látható böngészőt nyit.

A token-gazdaság gyakrabban dönt, mint a funkciók. Egy MCP-kör minden lépésben tool-sémákat és friss snapshottölt a kontextusba; egy CLI-parancs egy YAML-snapshot fájljának útját és egy státuszsor adja vissza. Egy hosszú életű agentnél, amelynek végig kell kattintania egy folyamatot, ez a különbség a kontextusba beférő és a beférni nem akaró munkamenet között.

A képernyőképek megvannak — egy eszközhívás, és a vision mód az egérre teszi a koordinátákat —, de pixelenként fogyasztanak tokent, és pontosan azt az egyértelműséget hozzák vissza, amit a snapshot-döntés eltávolított. Az accessibility fa egy összefoglaló, amire a modell cselekedhet; a képernyőkép bizonyíték, amit értelmeznie kell.

Árazás

A keretrendszer ingyenes, nincs Pro-kiadás, nincs ülőhelyszám és nincs felhasználási mérés. A költség három helyen jelenik meg: a CI-percek, amelyeket a suite eléget, a fejlesztői idő, amely zölden tartja, és — csak ha felügyelt grid kell — a Microsoft első féltől származó felhője.

• Keretrendszer: ingyenes Apache-2.0 alatt, korlátlan projekt és teszt, megújítandó licenc nélkül.
• Playwright Workspaces az Azure App Testingben: használathoz igazodva tesztpercenként, másodpercnyi pontossággal, egy 100 perces, 30 napos próbaidővel; azon túl a workspace átvált a mért csomagra, a közzétett árak pedig régiófüggők.
• A BrowserStackéhez hasonló külső grid-ek párhuzamos munkamenetenként vagy előfizetéssel számláznak, és csak valódi eszkökhöz, tágabb böngészőmátrixhoz vagy megfelelőséghez kellenek.
• A legnagyobb tétel sosem a licenc: a flaky tesztek kivizsgálása és a szelektorok gondozása az ismétlődő költség, és egyik csomag sem fedezi.

Mivel a futtató ingyenes, a migrációs kérdés általában időről szól, nem költségvetésről. A meglévő suite áthozása újraírt szelektorokat, fixture-öket és egyedi parancsokat jelent, a megtérülés pedig a második karbantartási hónappal jön, nem az első zöld buildtel.

Hol nyikorog

A gyengeségek ismertek és nagyrészt elfogadottak. A böngésző-binárok kiadáshoz kötöttek, a frissítés tehát tervezett feladat, amely a CI-image-eket is magával húzza. A futtató szélessége sok felület, mielőtt a csapat bármit is látna a shardingből és a trace-ekből. A WebKit itt patchelt build, nem maga a Safari, így egy Apple-specifikus hiba későn is előbukkannhat. Az CLI- és MCP-réteg pedig elég új, hogy a parancskészletek a minor kiadások között mozduljanak.

Az őszinte összehasonlítás a hatókörökről szól, nem a minőségről. A Selenium marad a válasz, ha szerződés vagy eszközhálózat követeli meg; a Cypress kényelmes a már belefektetett csapatoknak; a Puppeteer könyvtár, nem keretrendszer, és a szkript méretéhez való. A Playwright azt állítja, hogy egy eszköri mind a négy munkát — ennek a állításnak a karbantartási ára az a böngészőmátrix, amely most a CI-ben fut.

Ítélet

A Playwright a böngésző-automatizálás legerősebb alapértelmezése, az érdekes kérdés pedig már nem az, bevezeti-e valaki, hanem hogy három felületéből melyiket kinek teszi ki.

1. Vigye be új end-to-end munkához. A futtató, a kontextus-izoláció és a trace-nézegető a második hónaptól térül meg — éppen akkor, amikor a vékonyabb eszkörfajta drágább lesz.
2. Vigye be, ha agentnek kell vezérelnie a böngészőt. A refek és szerepek olcsóbbak és determináltabbak a pixeleknél, és a projekt maga gondozza az MCP- és CLI-utakat, nem a közösségre bízza.
3. Tervezze be a frissítési ritmust: a néhány hetente új böngésző-binárokat húzó kiadásvonal azt jelenti, hogy a lockfile, az image és a böngészők együtt mozognak, vagy sehogy.
4. Tartsa meg a Seleniumot, ahol a WebDriver vagy eszközhálózat szerződéses, és ne írja át a zöld Cypress suite-ot csak azért, mert a másik API szebb.
5. Ne kezelje review-ként a teszt-agenteket. A healer kihagyhat egy tesztet, amelyet töröttnek tart — ésszerű alapértelmezés, de rossz észrevétlenül hagyni.

A böngésző már nem csak az, amit tesztelnek; az is a felület, amelyet egy agent kezel. Azok az eszközök, amelyek strukturált állapotként mutatják — szerepek, refek, szöveg —, jobban öregszenek, mint amelyek pixeleként.

Források

1. Playwright-dokumentáció: telepítés
2. Playwright MCP: bevezető
3. Playwright CLI: bevezető
4. Playwright teszt-agentek
5. npm csomagmetaadatok az @playwright/testhez
6. Microsoft Learn: Playwright Workspaces próbaidő
7. Azure App Testing: díjszabás