Ako aktualizovať Playwright alebo Selenium bez rozbitia testovacej sady
Aktualizácia Playwrightu alebo Selenia nemusí byť pokus, po ktorom tím niekoľko dní opravuje testy naslepo. Bezpečný postup oddeľuje zmenu testovacieho frameworku od zmien prehliadača, drivera a prostredia priebežnej integrácie (CI). Vďaka tomu viete, čo sa zmenilo, ako výsledok overiť a ako sa vrátiť k poslednej funkčnej zostave.
Neaktualizujete iba jeden balík
Testovacia sada stojí na niekoľkých vrstvách. Patrí sem knižnica alebo test runner, runtime a ďalšie balíky, prehliadač, prípadný WebDriver, operačné knižnice a obraz použitý v CI. Zmena jednej vrstvy môže odkryť nekompatibilitu v inej.
Pri Playwrighte je táto väzba priamo súčasťou distribučného modelu. Každá verzia potrebuje konkrétne zostavy prehliadačov a po aktualizácii môže byť potrebné znova spustiť inštaláciu cez Playwright CLI. Opisuje to oficiálna dokumentácia k prehliadačom v Playwrighte. Samotná zmena položky v package.json preto nestačí.
Selenium funguje inak. Jazykový balík, prehliadač a driver, ktorý sprostredkuje ovládanie prehliadača, môžu mať samostatný životný cyklus. Ak testy bežia na Selenium Grid alebo u externého poskytovateľa, do výsledku vstupuje aj verzia vzdialeného uzla a jeho konfigurácia. Pred prácou si preto pomenujte celý aktualizačný balík, nie iba cieľovú verziu frameworku.
Najprv si uložte spoľahlivý východiskový stav
Pred aktualizáciou potrebujete baseline, teda výsledok poslednej známej konfigurácie, s ktorým porovnáte nový beh. Nestačí vedieť, že pipeline bola zelená. Zapíšte commit aplikácie a testov, presný príkaz, lockfile so zamknutými verziami závislostí, runtime, operačný systém alebo CI obraz, prehliadače, drivery, počet súbežných workerov a nastavenie opakovaných pokusov.
Na pôvodnej konfigurácii spustite aspoň kritické scenáre a plnú sadu v rovnakom rozsahu, v akom budete hodnotiť aktualizáciu. Uchovajte report, prvé zlyhania, trvanie a počet testov, ktoré prešli až na opakovaný pokus. Ak sada už pred zmenou náhodne padá, označte známe nestabilné testy. Inak ich po aktualizácii ľahko pripíšete novému frameworku.
Baseline má odpovedať aj na praktické otázky:
- Ktoré prehliadače a operačné systémy sú pre release povinné?
- Ktoré scenáre musia prejsť pred spojením vetvy?
- Aká miera známych zlyhaní a aké trvanie sú ešte prijateľné?
- Kto rozhodne o návrate, ak aktualizácia nesplní dohodnuté podmienky?
Podmienky stanovte ešte pred prvým novým behom. Po zlyhaní sa potom nerozhoduje podľa toho, koľko práce už tím do zmeny vložil.
Pripravte samostatnú vetvu aj cestu späť
Aktualizáciu robte v krátkodobej vetve nad známym commitom. Počas diagnostiky do nej nemiešajte zmeny aplikácie, nové testy ani veľké úpravy architektúry sady. Každá ďalšia premenná sťažuje rozlíšenie, či zlyhal produkt, test alebo prostredie.
Do repozitára patrí aktualizovaný manifest balíkov aj lockfile. V CI používajte čistú inštaláciu podľa lockfile, nie voľné dopočítanie novších tranzitívnych závislostí. Ak testy bežia v kontajneri, uložte aj presný tag alebo nemenný identifikátor obrazu. Playwright odporúča pripnúť Docker obraz ku konkrétnej verzii a zosúladiť ju s verziou projektu, pretože nezhoda môže zabrániť nájdeniu prehliadačových bináriek. Podrobnosti uvádza jeho dokumentácia k Dockeru.
Posledný funkčný lockfile a CI obraz musia zostať dostupné. Bez nich je „vrátime balík“ iba polovica rollbacku. Staršia knižnica s novým prehliadačom alebo driverom môže zlyhávať inak než pôvodná zostava.
Postup aktualizácie Playwrightu
Najskôr si prečítajte poznámky k vydaniam Playwrightu medzi používanou a cieľovou verziou. Hľadajte odstránené alebo zmenené rozhrania, nové systémové požiadavky, zmeny predvoleného správania a verzie prehliadačov. Cieľovú verziu zvoľte vedome. Príkaz s latest je vhodný na zistenie dostupnej verzie, nie ako trvalo neobmedzené pravidlo v CI.
Potom aktualizujte správny balík pre daný projekt a nechajte správcu balíkov vytvoriť nový lockfile. Pri projekte s Playwright Test pôjde zvyčajne o @playwright/test, pri inom zapojení môže ísť o knižnicu playwright. Nemeňte oba balíky naslepo, ak sada používa iba jeden z nich.
Po zmene balíka nainštalujte prehliadače určené novou verziou. V linuxovom CI môže príkaz npx playwright install --with-deps doplniť aj potrebné systémové závislosti. Ak používate oficiálny kontajner, zosúlaďte jeho verziu s projektom namiesto dodatočného sťahovania nesúvisiacej zostavy prehliadača.
Aspoň jeden overovací beh spustite na čistom runneri bez starej cache. Cache zrýchľuje bežnú pipeline, ale pri aktualizácii môže skryť chýbajúci inštalačný krok alebo ponechať binárku z predchádzajúcej verzie. Keď čistý beh prejde, cache môžete znovu zapojiť s kľúčom odvodeným od lockfile a zvolenej platformy.
Postup aktualizácie Selenia
Pri Seleniu najprv aktualizujte jazykový balík a jeho tranzitívne závislosti. Kompilácia alebo statická kontrola často odhalí zmenené API skôr než drahý end-to-end beh. Pri väčšom skoku si pozrite aj oficiálny návod na upgrade Selenia, ktorý oddeľuje prípravu kódu, aktualizáciu závislostí a riešenie odstránených rozhraní.
Potom skontrolujte, kto v skutočnosti vyberá driver. Selenium Manager je súčasťou distribúcie Selenia a jazykové knižnice ho použijú, keď driver nie je poskytnutý iným spôsobom. Dokáže zistiť nainštalovaný prehliadač, vyhľadať vhodný driver, stiahnuť ho a uložiť do cache. Ak však máte driver v PATH, zadávate jeho cestu priamo alebo používate externý manager, výsledné správanie môže byť iné.
Pre lokálne prostredie a CI zvoľte jednu zrozumiteľnú stratégiu. Buď nechajte Selenium Manager spravovať driver a zabezpečte mu rovnakú konfiguráciu, prístup k sieti a cache, alebo pripnite prehliadač s driverom v obraze či Grid uzle. Ručne stiahnutý driver ukrytý v starom CI obraze je častým zdrojom rozdielu medzi notebookom a pipeline.
Pri vzdialenom behu zaznamenajte požadované parametre relácie (capabilities) a adresu Gridu. Ak ich poskytovateľ uvádza, pridajte z reportu relácie aj skutočný prehliadač, platformu a driver. Aktualizácia klienta môže prejsť lokálne, no naraziť až pri vytvorení vzdialenej relácie.
Overujte po vrstvách, nie jedným plným behom
Najprv overte inštaláciu balíkov a zostavenie testov. Druhá vrstva je krátky smoke test, ktorý otvorí každý podporovaný prehliadač, načíta kontrolovanú stránku a vykoná jednoduchú interakciu. Tak rýchlo odlíšite problém so spustením prehliadača od chyby v obchodnom scenári.
Potom spustite kritické cesty so zachovanou konfiguráciou workerov, timeoutov a retry z baseline. Nasleduje plná sada v hlavnom CI prostredí a až po nej širšia matica prehliadačov a platforiem. Ak používate vizuálne porovnania, nové snímky neschvaľujte hromadne. Najprv overte, či rozdiel spôsobila oprávnená zmena vykresľovania a nie nesprávny font, rozlíšenie alebo operačná knižnica.
Zelený výsledok po retry rátajte ako signál nestability, nie ako čistý úspech. Porovnajte počet prvých zlyhaní, trvanie a rozdelenie chýb s baseline. Pri podozrivom rozdiele pomôže postup na porovnanie lokálneho a CI behu.
Diagnostikujte rozdiel podľa typu zlyhania
Chyba pri inštalácii alebo kompilácii smeruje k balíkom, runtime či odstránenému API. Neschopnosť vytvoriť reláciu ukazuje skôr na prehliadač, driver, systémové knižnice alebo Grid. Zlyhanie selektora či očakávania už môže súvisieť so zmenou správania nástroja, s vykreslením prehliadača alebo so skutočnou chybou aplikácie.
Pri prvom novom zlyhaní si ponechajte log, screenshot, trace alebo WebDriver log podľa možností sady. Zopakujte iba dotknutý test na starom aj novom prostredí, pričom nemeníte aplikáciu ani dáta. Ak výsledok ovláda jediná zmena verzie, máte použiteľnú reprodukciu. Hromadné zvýšenie timeoutov, zapnutie ďalších retry alebo osvieženie všetkých snapshotov túto informáciu zmaže.
Veľký skok rozdeľte na menšie rozhodnutia
Preskočenie mnohých vydaní môže naraz priniesť zmeny API, prehliadačov, runtime aj operačného systému. V takom prípade naplánujte medziverziu alebo oddeľte aktualizáciu runtime a CI obrazu od aktualizácie testovacieho nástroja. Každý medzikrok musí mať vlastný zelený commit a stručný záznam potrebných opráv.
Ak stará sada používa už odstránené API alebo nepodporované prostredie, nejde o bežnú údržbovú aktualizáciu. Najprv treba odhadnúť rozsah úprav a rozhodnúť, či má zmysel súčasnú sadu opraviť alebo časť scenárov preniesť. Samotné navyšovanie verzií takýto dlh nevyrieši.
Rollback musí vrátiť celú konfiguráciu
Spúšťač návratu si dohodnite vopred. Môže ním byť nefunkčná kritická cesta, nemožnosť spustiť podporovaný prehliadač, prekročenie tímového limitu nestability alebo neprijateľné predĺženie pipeline. Rollback potom vráti manifest, lockfile, CI obraz, konfiguráciu inštalácie prehliadačov a podľa potreby aj driver či Grid obraz ako jeden celok.
Po návrate spustite rovnaký smoke test a kritické scenáre ako pri baseline. Artefakty z neúspešnej vetvy zachovajte, aby sa ďalší pokus nezačínal od nuly. Rollback nie je náhrada opravy. Je to spôsob, ako udržať hlavnú vetvu použiteľnú, kým tím rieši konkrétnu nekompatibilitu.
Ako spoznáte úspešnú aktualizáciu
Aktualizácia je hotová, keď sa dá prostredie zostaviť z čistého runnera, všetky dohodnuté prehliadače vytvoria reláciu a kritické aj plné testy prejdú v určenom rozsahu. Výsledok nemá stáť na nových preskočeniach, slabších overeniach alebo väčšom počte opakovaných pokusov. Report má uvádzať verzie, s ktorými testy naozaj bežali, a tím musí vedieť rovnakú konfiguráciu obnoviť z repozitára.
Pri ďalšej aktualizácii už tím nebude znovu zisťovať, čo treba pripnúť, overiť a uložiť pre návrat. Zmena môže byť menšia a prebehne podľa rovnakého postupu. Ak testovacia sada nemá spoľahlivý baseline alebo sa jej prostredie nedá obnoviť, ozvite sa nám. Najprv pomôžeme oddeliť chyby sady od rozdielov v nástrojoch a infraštruktúre.