Ako spravovať karanténu nestabilných testov
Nestabilný test môže zablokovať zmenu, hoci pri opakovaní prejde bez úpravy kódu. Ak ho tím iba vypne, stratí kontrolu nad rizikom aj podklady na opravu. Karanténa je bezpečná len ako dočasný proces, v ktorom test zostáva viditeľný, spúšťa sa mimo blokujúcej vetvy a má vlastníka aj podmienky návratu.
Karanténa nie je priečinok na všetky červené testy
Do karantény patrí test, pri ktorom existuje dôkaz nestability za porovnateľných podmienok. Napríklad prvý pokus zlyhal, opakovanie na rovnakej verzii aplikácie a v rovnakom prostredí prešlo a zmena výsledku sa nedá vysvetliť úpravou očakávania. Jeden neúspešný beh nestačí. Môže ísť o chybu produktu, testu, dát alebo infraštruktúry.
Konzistentná chyba aplikácie nie je flaky len preto, že blokuje release. Ak platba pri rovnakých vstupoch zakaždým uloží nesprávnu sumu, test má zostať červený a tím má riešiť chybu produktu alebo vedome prijať riziko release. Presun do karantény by v takom prípade iba obišiel platnú kontrolu.
Opatrnosť si zaslúži aj chyba aplikácie, ktorá sa prejavuje len občas. Premenlivý výsledok ešte neznamená, že je chybný test. Súbeh požiadaviek, oneskorené spracovanie alebo chyba závislá od času môžu byť reálnym problémom produktu. Pred prijatím do karantény preto urobte prvé zatriedenie podľa postupu na meranie flaky testov. Nemusíte poznať koreňovú príčinu, potrebujete však vedieť, aké riziko dočasným oddelením prestáva blokovať release.
Stanovte vstupné pravidlá
O prijatí nemá rozhodovať unavený človek po niekoľkých opakovaniach pipeline. Dohodnite krátke pravidlá a používajte ich pri každom kandidátovi. Záznam má odpovedať aspoň na tieto otázky:
- ktorý test a ktorá konfigurácia sú nestabilné,
- kde je výsledok prvého zlyhania a následných pokusov,
- čo test overuje a aké produktové riziko dočasne prestane blokovať,
- kto schválil presun a kto vlastní opravu,
- kedy tím rozhodnutie znovu skontroluje,
- podľa čoho sa test vráti alebo odstráni.
Ak chýba prvé zlyhanie, kandidáta najprv spustite v kontrolovaných podmienkach a doplňte dôkazy. Ak chýba vlastník alebo termín kontroly, karanténu nevytvárajte. Takéto vyradenie by nemalo koniec.
Vlastník nemusí kód opraviť sám. Zodpovedá však za ďalšie rozhodnutie a za to, že položka nezostane bez reakcie. Toto rozdelenie nadväzuje na širšiu otázku, kto vlastní automatizované testy.
Termín kontroly nie je sľub, že dovtedy bude oprava hotová. Je to dátum, keď vlastník musí potvrdiť ďalší krok. Môže test vrátiť, predĺžiť karanténu s novým dôvodom, nahradiť ho inou kontrolou alebo navrhnúť odstránenie. Rozhodnutie o zmazaní má samostatné kritériá, ktoré opisuje článok o tom, ktoré automatizované testy zmazať.
Oddeľte iba najmenší potrebný rozsah
Ak scenár zlyháva iba vo Firefoxe, nevyradzujte jeho varianty pre ostatné prehliadače. Ak problém spôsobuje jediná kombinácia roly a dát, karanténa nemá stiahnuť celý súbor ani modul. Čím širší rozsah vypnete, tým viac platných kontrol prestane ovplyvňovať release.
Rovnaké pravidlo platí pri spoločnej príčine. Desať padajúcich testov môže zakrývať jeden chybný krok prípravy dát. Zaznamenajte ich pod spoločný incident, ale každý test označte tak, aby sa po oprave dal samostatne vyhodnotiť. Hromadné vypnutie adresára sťažuje návrat a skresľuje rozsah nepokrytého rizika.
Predstavte si nákupný scenár, ktorý občas zlyhá iba vo Firefoxe pri použití zľavového účtu. Do karantény presuňte túto kombináciu, nie celý nákup ani všetky prehliadače. Kontrola bežného nákupu môže ďalej blokovať zmenu. Ak neskôr rovnaké overenie začne konzistentne padať aj v ostatných prehliadačoch, incident znovu zatriedite. Karanténne označenie nesmie zabrániť tomu, aby tím rozpoznal nový a širší problém produktu.
Zachovajte prvé zlyhanie a jeho kontext
Opakovanie testu je užitočné, no nesmie prepísať prvý výsledok. Playwright pri zapnutých retries rozlišuje testy, ktoré prešli na prvý pokus, flaky testy, ktoré prešli až po opakovaní, a testy, ktoré neprešli ani po všetkých opakovaniach. Predvolene zlyhané testy neopakuje. Toto správanie opisuje oficiálna dokumentácia k Playwright retries.
Ku karanténnemu záznamu pripojte identifikátor commitu, verziu aplikácie, prostredie, prehliadač, použitú konfiguráciu, zlyhaný krok a chybovú správu. Uchovajte dostupný trace, log, snímku alebo sieťové údaje podľa citlivosti a pravidiel projektu. Dôležitý je aj výsledok každého opakovania, nie iba záverečná zelená značka.
Dôkazy kontrolujte ešte pred presunom. Ak nový pokus vyčistí dáta, reštartuje worker alebo použije iný účet, môže zlyhanie zmiznúť práve preto, že sa zmenili podmienky. Výsledok potom pomáha pri diagnostike, ale nepotvrdzuje, že pôvodný stav bol v poriadku. Report musí ukázať túto zmenu namiesto toho, aby všetky pokusy zlúčil do jedného výsledku.
Nechajte test bežať v samostatnej neblokujúcej vetve
Karanténa má oddeliť nedôveryhodný výsledok od rozhodnutia o zmene, nie zastaviť pozorovanie testu. Praktické nastavenie má dva behy. Hlavný CI beh vylúči označené testy a zostane blokujúci. Samostatný karanténny beh ich spustí nad rovnakým commitom v porovnateľnom prostredí, ale jeho výsledok nezastaví zlúčenie alebo nasadenie.
V Playwrighte možno na rozdelenie použiť vlastný tag a filtrovanie. Dokumentácia uvádza, že tagy sa dajú filtrovať cez --grep a vylúčiť cez --grep-invert. Vlastná anotácia môže niesť typ a opis, napríklad odkaz na úlohu, a je dostupná reportéru. Podrobnosti sú v dokumentácii k Playwright anotáciám. Tag ani anotácia však neurčia vlastníka, termín alebo prijaté riziko. Tie patria do procesu tímu.
Samostatný beh potrebuje pravidelný čas spustenia a upozornenie na výsledok. Ak sa vykonáva len ručne pri vyšetrovaní, medzi dvoma kontrolami neviete, či sa správanie zlepšilo, zhoršilo alebo sa test prestal dať spustiť úplne.
skip a fixme nie sú karanténny proces
Playwright test.skip() označí test ako nerelevantný a nespustí ho. test.fixme() ho tiež nespustí, pričom dokumentácia ho odporúča pre test, ktorého beh je pomalý alebo spôsobuje pád. Obe anotácie môžu byť užitočné pri konkrétnej konfigurácii, ale samy nevytvoria karanténu. Nevytvoria oddelený beh, nepridelia vlastníka a neurčia podmienky návratu.
Preskočenie je primerané, keď test v danej konfigurácii nemá význam, napríklad funkcia nie je pre určitý produktový variant dostupná. Flaky test však význam má. Ak ho označíte iba ako skip alebo fixme, prestanete získavať výsledky potrebné na opravu. Výnimkou môže byť test, ktorý poškodzuje prostredie alebo znemožní zvyšok behu. Aj vtedy má mať záznam, vlastníka a náhradný spôsob overenia rizika, kým ho nemožno bezpečne spúšťať.
Reportujte preskočené výsledky oddelene od úspešných
Zelený report nesmie počítať preskočený test ako úspešný dôkaz. V prehľade oddeľte minimálne testy úspešné na prvý pokus, flaky výsledky po retry, neúspešné testy, preskočené testy a výsledky karanténneho behu. Pri karanténe sledujte aj počet otvorených položiek, ich vek, prekročené termíny kontroly a riziká bez náhradného overenia.
Číselná hranica pre prijatie alebo návrat nebude rovnaká pre každý projekt. Jeden občas zlyhávajúci test môže chrániť platby, iný iba kozmetické zoradenie. O priorite opravy rozhoduje dopad chráneného scenára, frekvencia prvých zlyhaní, cena vyšetrovania a rozsah spätnej väzby, ktorú test zakrýva. Najskôr riešte položky, pri ktorých karanténa vytvorila najväčšiu medzeru alebo ktoré spotrebujú najviac času pri vyhodnocovaní.
Návrat musí mať vopred dohodnuté podmienky
Test sa nemá vrátiť iba preto, že ho niekto spustil raz lokálne a prešiel. Pred návratom musí byť jasná príčina alebo aspoň overené opatrenie, ktoré odstránilo pozorovaný mechanizmus zlyhania. Zmena prejde kontrolou kódu a test sa opakovane spustí v pôvodne problémových konfiguráciách. Tím si počet behov a dĺžku pozorovania určí podľa rizika a histórie, nie podľa univerzálneho percenta.
Pri výstupe skontrolujte, že test prechádza na prvý pokus, nie až po retry. Odstráňte karanténne označenie, vráťte scenár do blokujúceho behu a overte jeho výsledok priamo v CI. Až potom uzavrite úlohu s odkazom na opravu a výsledky overenia. Ak sa ukázalo, že scenár už nemá hodnotu, nejde o úspešný návrat z karantény, ale o zdokumentované rozhodnutie test nahradiť alebo odstrániť.
Čo riadená karanténa prinesie
Release prestane blokovať výsledok, ktorému tím zatiaľ nevie dôverovať, no problém nezmizne zo zorného poľa. Zachované prvé zlyhanie skracuje ďalšiu diagnostiku, samostatný beh ukazuje vývoj a vlastník s termínom bráni tomu, aby sa dočasné vypnutie zmenilo na trvalé.
Začnite inventúrou preskočených testov a výsledkov, ktoré prešli až po retry. Pri každom doplňte riziko, dôkaz, vlastníka a najbližší termín kontroly. Ak potrebujete nastaviť karanténu alebo vrátiť dlhodobo vyradené testy do CI, ozvite sa nám.