Jak spravovat karanténu nestabilních testů
Nestabilní test může zablokovat změnu, přestože při opakování projde bez úpravy kódu. Pokud ho tým pouze vypne, ztratí kontrolu nad rizikem i podklady k opravě. Karanténa je bezpečná jen jako dočasný proces, ve kterém test zůstává viditelný, spouští se mimo blokující větev a má vlastníka i podmínky návratu.
Karanténa není složka na všechny červené testy
Do karantény patří test, u kterého existuje důkaz nestability za srovnatelných podmínek. Například první pokus selhal, opakování na stejné verzi aplikace a ve stejném prostředí prošlo a změnu výsledku nelze vysvětlit úpravou očekávání. Jeden neúspěšný běh nestačí. Může jít o chybu produktu, testu, dat nebo infrastruktury.
Konzistentní chyba aplikace není flaky jen proto, že blokuje release. Pokud platba při stejných vstupech pokaždé uloží nesprávnou částku, test má zůstat červený a tým má řešit chybu produktu nebo vědomě přijmout riziko releasu. Přesun do karantény by v takovém případě pouze obešel platnou kontrolu.
Opatrnost vyžaduje také chyba aplikace, která se projevuje jen občas. Proměnlivý výsledek ještě neznamená, že je test chybný. Souběh požadavků, zpožděné zpracování nebo chyba závislá na čase mohou být skutečným problémem produktu. Před přijetím do karantény proto proveďte první zatřídění podle postupu pro měření flaky testů. Nemusíte znát kořenovou příčinu, potřebujete však vědět, jaké riziko po dočasném oddělení přestane blokovat release.
Stanovte vstupní pravidla
O přijetí nemá rozhodovat unavený člověk po několika opakováních pipeline. Dohodněte krátká pravidla a používejte je u každého kandidáta. Záznam má odpovědět alespoň na tyto otázky:
- který test a která konfigurace jsou nestabilní,
- kde je výsledek prvního selhání a následných pokusů,
- co test ověřuje a jaké produktové riziko dočasně přestane blokovat,
- kdo schválil přesun a kdo vlastní opravu,
- kdy tým rozhodnutí znovu zkontroluje,
- podle čeho se test vrátí nebo odstraní.
Pokud chybí první selhání, kandidáta nejprve spusťte v kontrolovaných podmínkách a doplňte důkazy. Bez vlastníka nebo termínu kontroly karanténu nevytvářejte. Takové vyřazení by nemělo konec.
Vlastník nemusí kód opravit sám. Odpovídá však za další rozhodnutí a za to, že položka nezůstane bez reakce. Toto rozdělení navazuje na širší otázku, kdo vlastní automatizované testy.
Termín kontroly není slib, že do té doby bude oprava hotová. Je to datum, kdy vlastník musí potvrdit další krok. Může test vrátit, prodloužit karanténu s novým důvodem, nahradit ho jinou kontrolou nebo navrhnout odstranění. Rozhodnutí o smazání má samostatná kritéria, která popisuje článek o tom, které automatizované testy smazat.
Oddělte jen nejmenší potřebný rozsah
Pokud scénář selhává pouze ve Firefoxu, nevyřazujte jeho varianty pro ostatní prohlížeče. Jestliže problém způsobuje jediná kombinace role a dat, karanténa nemá vyřadit celý soubor ani modul. Čím širší rozsah vypnete, tím více platných kontrol přestane ovlivňovat release.
Stejné pravidlo platí u společné příčiny. Deset padajících testů může zakrývat jeden chybný krok přípravy dat. Zaznamenejte je pod společný incident, ale každý test označte tak, aby šel po opravě samostatně vyhodnotit. Hromadné vypnutí adresáře ztěžuje návrat a zkresluje rozsah nepokrytého rizika.
Představte si nákupní scénář, který občas selže pouze ve Firefoxu při použití slevového účtu. Do karantény přesuňte tuto kombinaci, ne celý nákup ani všechny prohlížeče. Kontrola běžného nákupu může dál blokovat změnu. Pokud později stejné ověření začne konzistentně selhávat i v ostatních prohlížečích, incident znovu zatřiďte. Karanténní označení nesmí týmu zabránit rozpoznat nový a širší problém produktu.
Zachovejte první selhání a jeho kontext
Opakování testu je užitečné, nesmí však přepsat první výsledek. Playwright při zapnutých retries rozlišuje testy, které prošly na první pokus, flaky testy, které prošly až při opakování, a testy, které neprošly ani po všech opakováních. Ve výchozím nastavení neúspěšné testy neopakuje. Toto chování popisuje oficiální dokumentace k Playwright retries.
Ke karanténnímu záznamu připojte identifikátor commitu, verzi aplikace, prostředí, prohlížeč, použitou konfiguraci, neúspěšný krok a chybovou zprávu. Uchovejte dostupný trace, log, snímek nebo síťové údaje podle citlivosti a pravidel projektu. Potřebujete také výsledek každého opakování, ne pouze závěrečnou zelenou značku.
Důkazy zkontrolujte ještě před přesunem. Pokud nový pokus vyčistí data, restartuje worker nebo použije jiný účet, mohlo selhání zmizet právě proto, že se změnily podmínky. Výsledek pak pomáhá při diagnostice, ale nepotvrzuje, že původní stav byl v pořádku. Report musí změnu ukázat místo toho, aby všechny pokusy sloučil do jediného výsledku.
Nechte test běžet v samostatné neblokující větvi
Karanténa má oddělit nedůvěryhodný výsledek od rozhodnutí o změně, ne zastavit pozorování testu. Praktické nastavení má dva běhy. Hlavní CI běh vyloučí označené testy a zůstane blokující. Samostatný karanténní běh je spustí nad stejným commitem ve srovnatelném prostředí, ale jeho výsledek nezastaví sloučení nebo nasazení.
V Playwrightu lze k rozdělení použít vlastní tag a filtrování. Dokumentace uvádí, že tagy můžete filtrovat přes --grep a vyloučit přes --grep-invert. Vlastní anotace může obsahovat typ a popis, například odkaz na úkol, a je dostupná reportéru. Podrobnosti najdete v dokumentaci k Playwright anotacím. Tag ani anotace však neurčí vlastníka, termín nebo přijaté riziko. Ty patří do procesu týmu.
Samostatný běh potřebuje pravidelný čas spuštění a upozornění na výsledek. Pokud se provádí jen ručně při vyšetřování, mezi dvěma kontrolami nevíte, zda se chování zlepšilo, zhoršilo nebo se test přestal dát spustit úplně.
skip a fixme nejsou karanténní proces
Playwright test.skip() označí test jako nerelevantní a nespustí ho. test.fixme() ho také nespustí, přičemž dokumentace jej doporučuje pro test, jehož běh je pomalý nebo způsobuje pád. Obě anotace mohou být užitečné u konkrétní konfigurace, samy ale karanténu nevytvoří. Nevytvoří oddělený běh, nepřidělí vlastníka a neurčí podmínky návratu.
Přeskočení je namístě, když test v dané konfiguraci nemá význam, například funkce není pro určitou produktovou variantu dostupná. Flaky test ale význam má. Pokud ho označíte pouze jako skip nebo fixme, přestanete získávat výsledky potřebné k opravě. Výjimkou může být test, který poškozuje prostředí nebo znemožní zbytek běhu. I tehdy má mít záznam, vlastníka a náhradní způsob ověření rizika, dokud ho nelze bezpečně spouštět.
Reportujte přeskočené výsledky odděleně od úspěšných
Zelený report nesmí počítat přeskočený test jako úspěšný důkaz. V přehledu oddělte minimálně testy úspěšné na první pokus, flaky výsledky po retry, neúspěšné testy, přeskočené testy a výsledky karanténního běhu. U karantény sledujte také počet otevřených položek, jejich stáří, překročené termíny kontroly a rizika bez náhradního ověření.
Číselná hranice pro přijetí nebo návrat nebude stejná pro každý projekt. Jeden občas selhávající test může chránit platby, jiný jen kosmetické řazení. O prioritě opravy rozhoduje dopad chráněného scénáře, četnost prvních selhání, cena vyšetřování a rozsah zpětné vazby, kterou test zakrývá. Nejdříve řešte položky, u kterých karanténa vytvořila největší mezeru nebo které spotřebují nejvíce času při vyhodnocování.
Návrat musí mít předem dohodnuté podmínky
Test se nemá vrátit jen proto, že ho někdo jednou spustil lokálně a prošel. Před návratem musí být jasná příčina nebo alespoň ověřené opatření, které odstranilo pozorovaný mechanismus selhání. Změna projde kontrolou kódu a test se opakovaně spustí v původně problémových konfiguracích. Počet běhů a délku pozorování si tým určí podle rizika a historie, ne podle univerzálního procenta.
Při výstupu zkontrolujte, že test prochází na první pokus, ne až po retry. Odstraňte karanténní označení, vraťte scénář do blokujícího běhu a ověřte jeho výsledek přímo v CI. Teprve potom uzavřete úkol s odkazem na opravu a výsledky ověření. Pokud se ukázalo, že scénář už nemá hodnotu, nejde o úspěšný návrat z karantény, ale o zdokumentované rozhodnutí test nahradit nebo odstranit.
Co řízená karanténa přinese
Release přestane blokovat výsledek, kterému tým zatím nemůže důvěřovat, problém ale nezmizí ze zorného pole. Zachované první selhání zkracuje další diagnostiku, samostatný běh ukazuje vývoj a vlastník s termínem brání tomu, aby se dočasné vypnutí změnilo na trvalé.
Začněte inventurou přeskočených testů a výsledků, které prošly až po retry. U každého doplňte riziko, důkaz, vlastníka a nejbližší termín kontroly. Pokud potřebujete nastavit karanténu nebo vrátit dlouhodobě vyřazené testy do CI, ozvěte se nám.