Proč testy náhodně selhávají a jak je stabilizovat
Test jednou selže a při opakovaném spuštění projde bez změny kódu. Takový test se označuje jako nestabilní neboli flaky. Pokud k tomu dochází často, tým neví, zda má řešit chybu aplikace, testu nebo prostředí, a zpětná vazba z automatizace ztrácí hodnotu.
V čem je problém: nejčastější zdroje nestability
Test není navázaný na stav aplikace. Pevné čekání, například dvě sekundy, může na rychlém stroji stačit, ale na zatíženém ne. Problém může vzniknout také tehdy, když test čeká pouze na zobrazení prvku, nikoli na dokončení operace, kterou potřebuje ověřit.
Selektor je navázaný na vzhled. Přesná cesta v HTML nebo generovaná CSS třída se může při redesignu změnit, aniž by se změnilo chování. Test potom nedokáže prvek najít, přestože ho uživatel stále vidí.
Testy sdílejí stav. Dva souběžné scénáře používají stejný účet, objednávku nebo nastavení. Jeden změní data, která druhý právě očekává, a výsledek závisí na pořadí běhů.
Prostředí nebo externí služba kolísá. Testovací prostředí může být přetížené, databáze nemusí obsahovat očekávaná data nebo platební brána odpoví pozdě. Pokud je externí služba předmětem testu, jde o relevantní výsledek. Pokud není, její výpadek zbytečně zakryje stav vaší aplikace.
Scénář závisí na čase a pořadí. Časové pásmo, konec měsíce, vypršení platnosti tokenu nebo test, který může projít pouze po jiném testu, vytvářejí výsledky, které se na jiném stroji obtížně reprodukují.
Jak postupovat při stabilizaci
Nejprve shromažďujte historii: název testu, prostředí, prohlížeč, dobu trvání, chybovou zprávu a výsledek opakování. Teprve potom oddělte chyby aplikace od problémů testu a infrastruktury. Podrobnější postup nabízí článek jak měřit nestabilní testy.
Pevné pauzy nahraďte čekáním na konkrétní stav, například dokončenou odpověď nebo viditelný výsledek operace. Playwright před běžnými akcemi automaticky kontroluje připravenost prvku a jeho opakovaná ověření dokážou čekat na očekávaný stav. To pomáhá, ale nevyřeší nesprávná data ani nestabilní službu.
Prvky vyhledávejte podle významu pro uživatele, například podle role a názvu, nebo podle dohodnutého testovacího identifikátoru. Každý test by si měl připravit vlastní data a dokázat běžet nezávisle na pořadí. Externí závislost simulujte pouze tehdy, když není cílem daného testu; integrační ověření ponechte v samostatné vrstvě.
Opakované části rozhraní lze oddělit pomocí Page Object Modelu. Tento vzor omezuje duplicitu, ale nenahrazuje správné čekání a izolaci dat.
Na co si dát pozor
Automatické opakování neúspěšného testu je užitečné pro sběr důkazů nebo dočasné udržení pipeline, ale nesmí problém skrýt. Sledujte, kolik testů projde až na druhý pokus, a vytvořte plán jejich opravy. Při diagnostice může podle konfigurace pomoci trace, snímek nebo video; žádný záznam však nenahradí jasnou chybovou zprávu a kontrolu očekávaného výsledku.
Co tím získáte
- Tým rychleji rozliší chybu produktu od problému testu nebo prostředí.
- Méně času se ztratí opakovaným spouštěním a ručním ověřováním.
- Testy lze bezpečněji spouštět souběžně a při releasech.
- Důvěra ve výsledky automatizace se postupně obnoví.
Další krok
Vyberte testy, které v posledních týdnech prošly až při opakovaném pokusu, a seřaďte je podle frekvence a dopadu. Pokud chcete příčiny systematicky změřit a odstranit, ozvěte se nám. Navrhneme, co opravit u zdroje a co dočasně oddělit od hlavní pipeline.