Jak měřit flaky testy a odhalit nestabilní scénáře
Když stejný test jednou selže a jindy projde bez zjevné změny, mluvíme o nestabilním neboli flaky výsledku. Samotné opakování testu však neukáže, zda je problém v jeho kódu, aplikaci, datech nebo prostředí. Stabilizace proto začíná měřením, ne prodlužováním časových limitů.
Proč jeden neúspěšný běh nestačí
Stejná chybová zpráva může mít různé příčiny:
- Chyba aplikace: test správně odhalil nesprávné chování, které může záviset na čase nebo souběhu.
- Chyba testu: test nepočkal na správný stav, použil křehký selektor nebo předpokládal nevhodné pořadí.
- Problém dat či prostředí: chyběl očekávaný záznam, služba odpovídala pomalu nebo infrastruktura neměla potřebnou kapacitu.
Pokud se test pouze spustí znovu a jeho první výsledek se zahodí, tým ztratí důkaz potřebný k rozlišení těchto možností. Počet opakování časem roste, ale příčina zůstává.
Co se vyplatí zaznamenávat
Základem je historie jednotlivých pokusů, ne pouze konečný zelený nebo červený stav pipeline. U každého testu sledujte:
- výsledek prvního pokusu i případného opakování,
- dobu běhu a místo, kde test selhal,
- chybovou zprávu a její opakující se vzorec,
- verzi aplikace, prohlížeč, testovací prostředí a počet souběžných workerů,
- použitý účet nebo identifikátor testovacích dat,
- dostupné diagnostické údaje, například log, trace nebo snímek.
Dvě praktické metriky jsou podíl neúspěšných prvních pokusů a podíl testů, které projdou až po opakování. Druhá metrika ukáže nestabilitu, kterou může konečný zelený report skrýt. Neexistuje jedno vhodné procento pro každý projekt; prioritu určujte také podle toho, zda test chrání kritický proces.
Jak provést kontrolované měření
1. Zafixujte výchozí podmínky
Vyberte stejnou verzi aplikace, známou konfiguraci a kontrolovaná data. Sadu spusťte několikrát beze změny těchto podmínek. Rozdílný výsledek je signálem nestability, ne automatickým důkazem, že je chyba v samotném testu.
2. Měňte vždy jednu podmínku
Porovnejte běh jednoho testu se souběžným během celé sady. Pokud problém vzniká pouze při souběhu, testy mohou sdílet data nebo zdroje. Porovnání rychlejšího a pomalejšího prostředí může odhalit nevhodné čekání. Rozdíl mezi prohlížeči může být chyba kompatibility, ne flaky test.
3. Seskupte stejná selhání
Deset testů může selhávat kvůli jedné společné příčině, například nedostupnému přihlášení nebo chybě při přípravě dat. Seskupení podle chybové zprávy a místa selhání zabrání tomu, aby tým opravoval každý příznak samostatně.
4. Rozdělte výsledky podle dalšího kroku
- opravit test nebo jeho data,
- prověřit chybu aplikace,
- stabilizovat prostředí,
- dočasně oddělit test od blokující sady a určit termín opravy,
- po dohodě odstranit test, který je zastaralý nebo duplikuje jinou kontrolu.
Dočasné oddělení nesmí znamenat, že test zmizí bez vlastníka. V reportu má zůstat viditelný včetně důvodu a data dalšího rozhodnutí.
Na co si dát pozor
Zvýšení časového limitu může být oprávněné, pokud aplikace na danou operaci skutečně potřebuje více času. Není však univerzální opravou. Pokud test čeká na nesprávný signál nebo používá sdílená data, delší limit pouze odloží selhání a prodlouží každý běh.
Stejně opatrně přistupujte k mazání. Test může vypadat neaktuálně, ale přitom pokrývat důležitý okrajový případ. Před odstraněním potvrďte jeho účel s člověkem, který rozumí produktu.
Co tím získáte
- Konkrétní seznam nestabilních testů místo obecného dojmu.
- Rozdělení příčin mezi test, aplikaci, data a prostředí.
- Pořadí oprav podle četnosti a dopadu na uživatele.
- Metriky, kterými lze po opravě potvrdit zlepšení.
Další krok
Začněte výsledky prvních pokusů z posledních releasů a označte testy, které prošly až po opakování. Pokud historii nemáte, ozvěte se nám. Navrhneme krátké kontrolované měření a rozdělíme sadu na testy určené k opravě, prověření nebo vyřazení. Pokud je překážkou nepodporovaný nástroj, může být vhodnější portace testů.