Jak aktualizovat Playwright nebo Selenium bez rozbití testovací sady
Aktualizace Playwrightu nebo Selenia nemusí být pokus, po kterém tým několik dní naslepo opravuje testy. Bezpečný postup odděluje změnu testovacího frameworku od změn prohlížeče, driveru a prostředí průběžné integrace (CI). Díky tomu víte, co se změnilo, jak výsledek ověřit a jak se vrátit k poslední funkční sestavě.
Neaktualizujete jen jeden balíček
Testovací sada stojí na několika vrstvách. Patří sem knihovna nebo test runner, runtime a další balíčky, prohlížeč, případný WebDriver, systémové knihovny a obraz použitý v CI. Změna jedné vrstvy může odkrýt nekompatibilitu v jiné.
U Playwrightu je tato vazba přímo součástí distribučního modelu. Každá verze potřebuje konkrétní sestavení prohlížečů a po aktualizaci může být nutné znovu spustit instalaci přes Playwright CLI. Popisuje to oficiální dokumentace k prohlížečům v Playwrightu. Samotná změna položky v package.json proto nestačí.
Selenium funguje jinak. Jazykový balíček, prohlížeč a driver, který zprostředkuje ovládání prohlížeče, mohou mít samostatný životní cyklus. Pokud testy běží na Selenium Grid nebo u externího poskytovatele, výsledek ovlivňuje i verze vzdáleného uzlu a jeho konfigurace. Před zahájením práce proto pojmenujte celý aktualizační balík, ne pouze cílovou verzi frameworku.
Nejprve si uložte spolehlivý výchozí stav
Před aktualizací potřebujete baseline, tedy výsledek poslední známé konfigurace, se kterým porovnáte nový běh. Nestačí vědět, že pipeline byla zelená. Zapište commit aplikace a testů, přesný příkaz, lockfile se zamčenými verzemi závislostí, runtime, operační systém nebo CI obraz, prohlížeče, drivery, počet souběžných workerů a nastavení opakovaných pokusů.
Na původní konfiguraci spusťte alespoň kritické scénáře a celou sadu ve stejném rozsahu, v jakém budete hodnotit aktualizaci. Uchovejte report, první selhání, dobu běhu a počet testů, které prošly až na opakovaný pokus. Pokud sada padá náhodně už před změnou, označte známé nestabilní testy. Jinak je po aktualizaci snadno připíšete novému frameworku.
Baseline má odpovědět i na praktické otázky:
- Které prohlížeče a operační systémy jsou pro release povinné?
- Které scénáře musí projít před sloučením větve?
- Jaká míra známých selhání a jaká doba běhu jsou ještě přijatelné?
- Kdo rozhodne o návratu, pokud aktualizace nesplní dohodnuté podmínky?
Podmínky stanovte před prvním novým během. Po selhání se pak nerozhoduje podle toho, kolik práce už tým do změny vložil.
Připravte samostatnou větev i cestu zpět
Aktualizaci provádějte v krátkodobé větvi nad známým commitem. Během diagnostiky do ní nemíchejte změny aplikace, nové testy ani rozsáhlé úpravy architektury sady. Každá další proměnná ztěžuje rozlišení, zda selhal produkt, test, nebo prostředí.
Do repozitáře patří aktualizovaný manifest balíčků i lockfile. V CI používejte čistou instalaci podle lockfile, ne volný výpočet novějších tranzitivních závislostí. Pokud testy běží v kontejneru, uložte i přesný tag nebo neměnný identifikátor obrazu. Playwright doporučuje připnout Docker obraz ke konkrétní verzi a sladit ji s verzí projektu, protože neshoda může zabránit nalezení binárních souborů prohlížečů. Podrobnosti uvádí jeho dokumentace k Dockeru.
Poslední funkční lockfile a CI obraz musí zůstat dostupné. Bez nich je „vrátíme balíček“ jen polovina rollbacku. Starší knihovna s novým prohlížečem nebo driverem může selhávat jinak než původní sestava.
Postup aktualizace Playwrightu
Nejprve si přečtěte poznámky k vydáním Playwrightu mezi používanou a cílovou verzí. Hledejte odstraněná nebo změněná rozhraní, nové systémové požadavky, změny výchozího chování a verze prohlížečů. Cílovou verzi zvolte vědomě. Příkaz s latest se hodí ke zjištění dostupné verze, ne jako trvale neomezené pravidlo v CI.
Potom aktualizujte správný balíček pro daný projekt a nechte správce balíčků vytvořit nový lockfile. U projektu s Playwright Test půjde obvykle o @playwright/test, u jiného zapojení může jít o knihovnu playwright. Neměňte oba balíčky naslepo, pokud sada používá jen jeden z nich.
Po změně balíčku nainstalujte prohlížeče určené novou verzí. V linuxovém CI může příkaz npx playwright install --with-deps doplnit i potřebné systémové závislosti. Pokud používáte oficiální kontejner, slaďte jeho verzi s projektem místo dodatečného stahování nesouvisejícího sestavení prohlížeče.
Alespoň jeden ověřovací běh spusťte na čistém runneru bez staré cache. Cache zrychluje běžnou pipeline, ale při aktualizaci může skrýt chybějící instalační krok nebo ponechat binární soubor z předchozí verze. Jakmile čistý běh projde, můžete cache znovu zapojit s klíčem odvozeným od lockfile a zvolené platformy.
Postup aktualizace Selenia
U Selenia nejprve aktualizujte jazykový balíček a jeho tranzitivní závislosti. Kompilace nebo statická kontrola často odhalí změněné API dříve než nákladný end-to-end běh. U většího skoku se podívejte i do oficiálního návodu k upgradu Selenia, který odděluje přípravu kódu, aktualizaci závislostí a řešení odstraněných rozhraní.
Potom zkontrolujte, kdo ve skutečnosti vybírá driver. Selenium Manager je součástí distribuce Selenia a jazykové knihovny jej použijí, pokud není driver poskytnut jiným způsobem. Dokáže zjistit nainstalovaný prohlížeč, vyhledat vhodný driver, stáhnout jej a uložit do cache. Pokud však máte driver v PATH, zadáváte jeho cestu přímo nebo používáte externí manager, výsledné chování může být jiné.
Pro lokální prostředí a CI zvolte jednu srozumitelnou strategii. Buď nechte Selenium Manager spravovat driver a zajistěte mu stejnou konfiguraci, přístup k síti a cache, nebo připněte prohlížeč s driverem v obrazu či Grid uzlu. Ručně stažený driver ukrytý ve starém CI obrazu bývá zdrojem rozdílu mezi notebookem a pipeline.
Při vzdáleném běhu zaznamenejte požadované parametry relace (capabilities) a adresu Gridu. Pokud je poskytovatel uvádí, přidejte z reportu relace i skutečný prohlížeč, platformu a driver. Aktualizace klienta může projít lokálně, ale narazit až při vytvoření vzdálené relace.
Ověřujte po vrstvách, ne jedním úplným během
Nejprve ověřte instalaci balíčků a sestavení testů. Druhou vrstvou je krátký smoke test, který otevře každý podporovaný prohlížeč, načte kontrolovanou stránku a provede jednoduchou interakci. Tak rychle odlišíte problém se spuštěním prohlížeče od chyby v obchodním scénáři.
Potom spusťte kritické cesty se zachovanou konfigurací workerů, timeoutů a retry z baseline. Následuje celá sada v hlavním CI prostředí a až po ní širší matice prohlížečů a platforem. Pokud používáte vizuální porovnání, neschvalujte nové snímky hromadně. Nejdříve ověřte, zda rozdíl způsobila oprávněná změna vykreslování, a ne chybný font, rozlišení nebo systémová knihovna.
Zelený výsledek po retry počítejte jako signál nestability, ne jako čistý úspěch. Porovnejte počet prvních selhání, dobu běhu a rozdělení chyb s baseline. U podezřelého rozdílu pomůže postup pro porovnání lokálního a CI běhu.
Diagnostikujte rozdíl podle typu selhání
Chyba při instalaci nebo kompilaci směřuje k balíčkům, runtime či odstraněnému API. Nemožnost vytvořit relaci ukazuje spíše na prohlížeč, driver, systémové knihovny nebo Grid. Selhání selektoru či očekávání už může souviset se změnou chování nástroje, vykreslením prohlížeče nebo skutečnou chybou aplikace.
U prvního nového selhání si ponechte log, screenshot, trace nebo WebDriver log podle možností sady. Zopakujte pouze dotčený test ve starém i novém prostředí, přičemž neměňte aplikaci ani data. Pokud výsledek ovládá jediná změna verze, máte použitelnou reprodukci. Hromadné zvýšení timeoutů, zapnutí dalších retry nebo obnovení všech snapshotů tuto informaci smaže.
Velký skok rozdělte na menší rozhodnutí
Přeskočení mnoha vydání může současně přinést změny API, prohlížečů, runtime i operačního systému. V takovém případě naplánujte meziverzi nebo oddělte aktualizaci runtime a CI obrazu od aktualizace testovacího nástroje. Každý mezikrok musí mít vlastní zelený commit a stručný záznam potřebných oprav.
Pokud stará sada používá už odstraněné API nebo nepodporované prostředí, nejde o běžnou aktualizaci v rámci údržby. Nejdříve je třeba odhadnout rozsah úprav a rozhodnout, zda má smysl současnou sadu opravit, nebo část scénářů přenést. Samotné navyšování verzí takový dluh nevyřeší.
Rollback musí vrátit celou konfiguraci
Spouštěč návratu si dohodněte předem. Může jím být nefunkční kritická cesta, nemožnost spustit podporovaný prohlížeč, překročení týmového limitu nestability nebo nepřijatelné prodloužení pipeline. Rollback pak vrátí manifest, lockfile, CI obraz, konfiguraci instalace prohlížečů a podle potřeby i driver či Grid obraz jako jeden celek.
Po návratu spusťte stejný smoke test a kritické scénáře jako u baseline. Artefakty z neúspěšné větve zachovejte, aby další pokus nezačínal od nuly. Rollback nenahrazuje opravu. Udržuje hlavní větev použitelnou, zatímco tým řeší konkrétní nekompatibilitu.
Jak poznáte úspěšnou aktualizaci
Aktualizace je hotová, když lze prostředí sestavit z čistého runneru, všechny dohodnuté prohlížeče vytvoří relaci a kritické i úplné testy projdou v určeném rozsahu. Výsledek nesmí stát na nových přeskočeních, slabších ověřeních nebo větším počtu opakovaných pokusů. Report má uvádět verze, se kterými testy skutečně běžely, a tým musí umět stejnou konfiguraci obnovit z repozitáře.
Při další aktualizaci už tým nebude znovu zjišťovat, co má připnout, ověřit a uložit pro návrat. Změna může být menší a proběhne podle stejného postupu. Pokud testovací sada nemá spolehlivý baseline nebo její prostředí nelze obnovit, ozvěte se nám. Nejprve pomůžeme oddělit chyby sady od rozdílů v nástrojích a infrastruktuře.