Jan Mikoláš
Slovník pojmů
Playwright
Playwright ověřuje to, co uživatel skutečně projde v prohlížeči. Je proto cenný pro kritické cesty, ale nemá nahrazovat rychlé unit a cílené integrační testy.
Stručná definice
Automatizovaný prohlížeč pro ověření uživatelského výsledku.
Playwright Test spojuje test runner, assertions, izolované browser contexts, paralelní běh a nástroje pro diagnostiku. Test může otevřít stránku, vyplnit formulář, kliknout na tlačítko a ověřit, že se uživatel dostal do očekávaného stavu.
Podporuje prohlížeče Chromium, Firefox a WebKit. Vedle desktopových projektů umí nastavit mobilní viewport a vybrané charakteristiky zařízení; emulace ale není totéž co úplné ověření na každém fyzickém telefonu.
Jaký problém řeší
Chyby vznikající až při spolupráci prohlížeče a aplikace
End-to-end test má velký rozsah a je pomalejší, proto je vhodné jím chránit hlavně cesty s významem pro uživatele nebo peníze.
- přihlášení, práce s relací a ochrana stránky pro nepřihlášeného uživatele
- vyhledání produktu, vložení do košíku a validace checkoutu
- správné zobrazení chyb po odeslání formuláře
- propojení frontendového formuláře s reálným HTTP endpointem a odpovědí
- ověření kritického chování napříč podporovanými prohlížeči před vydáním
Praktický příklad
E-shopový tok od produktu k validaci checkoutu
Scénář otevře konkrétní produkt, vloží jej do košíku a přejde k objednávce. Neověřuje interní store frontendu, ale to, že uživatel po odeslání neúplného formuláře uvidí srozumitelnou validaci a objednávka se neodešle. Data produktu musí test připravit tak, aby nebyl závislý na náhodném katalogu.
Použité role a labely podporují zároveň přístupnost. Pokud se změní vzhled tlačítka, ale zachová se jeho uživatelský význam, test zůstává stabilnější než dlouhý CSS selector.
TypeScript
import { expect, test } from '@playwright/test';
test('zobrazí validaci neúplného checkoutu', async ({ page }) => {
await page.goto('/produkt/bezdratova-mys');
await page.getByRole('button', { name: 'Přidat do košíku' }).click();
await page.getByRole('link', { name: 'Přejít do košíku' }).click();
await page.getByRole('button', { name: 'Objednat' }).click();
await expect(page.getByText('Vyplňte e-mail')).toBeVisible();
});Jak funguje
Izolovaný scénář od prohlížeče po assertion
Přesné nastavení se liší podle aplikace, ale test nemá záviset na výsledku předchozího běhu ani na náhodném okamžiku načítání.
- Browser a context Runner spustí zvolený prohlížeč. Každý test dostane vlastní browser context, tedy izolovaný profil s vlastním stavem.
- Page Page představuje kartu či stránku prohlížeče; test na ní naviguje, čte viditelný stav a provádí akce.
- Locator Locator popisuje hledaný prvek a při akci jej znovu vyhledá. Přednost mají role, label nebo jiný stabilní uživatelský kontrakt.
- Akce a čekání Před kliknutím nebo vyplněním Playwright čeká na potřebnou akčnost prvku. Assertions se opakují, dokud očekávaný stav nenastane nebo nevyprší timeout.
- Výsledek a diagnostika Při selhání lze uložit screenshot, video nebo trace; artefakty mají pomoci najít příčinu, ne zakrýt flaky test opakováním.
Hlavní části
Stabilní test stojí na dobrém výběru prvků a pozorovatelném stavu
API nástroje je široké, ale pro každodenní testy je důležitější několik disciplinovaných návyků než složitý wrapper.
Locatory
getByRole() s přístupným jménem obvykle odpovídá tomu, jak prvek vnímá uživatel a asistivní technologie. Pro pole je vhodný label, pro výslovný testovací kontrakt data-testid. Dlouhé CSS nebo XPath řetězce se lámou při běžné změně HTML.
Web-first assertions
expect(locator).toBeVisible() nebo toHaveText() ověřuje uživatelsky pozorovatelný stav a umí čekat. Kontrola interní implementace či JavaScriptové proměnné bývá křehčí a méně hodnotná.
Auto-waiting
Akce čekají, až je cíl například viditelný, stabilní a schopný přijmout vstup. Pevné sleep prodlevy tento mechanismus obcházejí a zrychlení nebo zpomalení CI pak vyrábí nespolehlivé testy.
Fixtures a isolation
Vestavěné fixtures poskytují page a další prostředky s jasným životním cyklem. Test má připravit vlastní data nebo bezpečně použít izolovaný stav, ne spoléhat na účet a košík z předchozího testu.
Projekty a paralelní běh
Konfigurace může definovat Chromium, Firefox, WebKit i mobilní emulaci. Paralelní běh šetří čas, ale odhalí sdílené účty, kolizní testovací data a závislost na pořadí.
Co Playwright je a není
Prohlížečový test má jiný rozsah než unit nebo HTTP test
Pyramidová strategie obvykle ponechá většinu pravidel v rychlejších testech a E2E sadě vybere jen důležité cesty.
- Unit test
- Ověřuje malou část logiky bez skutečného prohlížeče, obvykle rychle a s přesně řízenými závislostmi. Playwright ho nenahrazuje.
- Integrační HTTP test
- Ověřuje endpoint, validaci nebo odpověď aplikace přes HTTP. Neověří však nutně, zda tlačítko, formulář, navigace a klientský stav fungují pro uživatele dohromady.
- PHPUnit
- PHPUnit je PHP framework a runner pro různé druhy testů. Playwright je prohlížečová automatizace se svým JavaScriptovým či jiným podporovaným jazykovým API a test runnerem.
- Screenshot, video a trace
- Jsou to diagnostické artefakty. Screenshot zachytí obraz, video průběh a trace kroky, síť či DOM pro analýzu; nejsou samy o sobě důkazem správného scénáře.
Výhody a omezení
Silná ochrana kritické cesty za cenu širšího testovacího prostředí
Přínosy
- ověření skutečného uživatelského toku v prohlížeči
- auto-waiting a web-first assertions podporují čitelnější a stabilnější testy
- stejný scénář lze spouštět v několika browser projektech
- trace a další artefakty urychlují hledání příčiny selhání v CI
Omezení a časté chyby
- příliš mnoho pomalých E2E scénářů místo menších testů pravidel
- sleep a přehnané timeouty maskující závod nebo pomalou závislost
- sdílená data, účty a pořadí testů vedoucí k náhodnému selhání
- locatory navázané na křehkou strukturu CSS místo chování, role nebo labelu
Pragmatické použití
Testovat výsledek pro uživatele, ne každý interní krok aplikace.
E2E scénář má být krátký, čitelný a zaměřený na hodnotu, kterou nelze levněji ověřit níže v testovací sadě. Checkout, reset hesla nebo oprávnění uživatele jsou dobrými kandidáty. Výpočet DPH nebo validaci samotné hodnoty je obvykle rychlejší a přesnější ověřit mimo prohlížeč.
V CI je lepší spouštět malou spolehlivou sadu nad řízeným testovacím prostředím než mnoho scénářů proti náhodně sdílenému stagingu. Externí platby, e-mail a třetí strany je potřeba izolovat, simulovat v řízené hranici nebo vybavit bezpečným testovacím účtem.
Na co myslet
Stabilita je vlastnost návrhu testu, ne nastavení retry
Retry může pomoci diagnostikovat přechodný problém, ale nesmí být běžným způsobem, jak přijmout nespolehlivý test.
- používat role, labely a testovací identifikátory s jasným kontraktem
- čekat na skutečný viditelný nebo síťový stav, ne na pevný čas
- pro každý test vytvořit nebo obnovit potřebná data a identitu
- oddělit kritické E2E toky od rychlých unit a integračních sad
- v CI ukládat trace nebo screenshot při selhání pro dohledání příčiny
- pravidelně odstraňovat duplicitní scénáře a testy závislé na implementačním detailu
Časté otázky
Playwright v testovací strategii
Je Playwright náhrada za PHPUnit?
Ne. PHPUnit je PHP testovací framework, zatímco Playwright ovládá prohlížeč a ověřuje E2E scénáře. Většina business pravidel zůstává rychlejší a přesnější v unit či integračních testech.
Proč nepoužít sleep po kliknutí?
Pevný čas neví, zda je aplikace skutečně hotová: někdy jen zdržuje a jindy nestačí. Locatorové akce a assertions umějí čekat na konkrétní akčnost nebo viditelný výsledek.
Jsou CSS selektory vždy špatně?
Ne, ale dlouhé selektory provázané se strukturou DOM jsou křehké. Pro interaktivní prvky jsou obvykle stabilnější role s přístupným jménem, label nebo vědomě vytvořený test id.
Musí se každý test spouštět ve všech prohlížečích?
Záleží na podporované platformě a riziku změny. Je rozumné definovat browser projekty pro skutečně podporované prostředí a vybrat, která sada musí projít všude a která může běžet rychleji.
Jak přistupuji k testování
Nejdůležitější toky ověřuji od uživatelského výsledku po integraci aplikace.
Testovací sadu skládám tak, aby rychlé kontroly pokryly pravidla a prohlížečové scénáře chránily jen skutečně důležité cesty uživatele.