Automatizované testy v CI/CD: co spouštět při pull requestu, po nasazení a v noci
CI/CD je automatizovaný proces sestavení, kontroly a nasazení softwaru. Přidat do něj testy však neznamená spustit celou regresi při každé změně. Užitečný návrh poskytne rychlou odpověď vývojáři při pull requestu, důkladnější kontrolu před releasem a srozumitelný signál po nasazení – aniž by pomalá nebo nestabilní sada blokovala tým.
Proč jedna testovací úloha nestačí
Testy mají rozdílnou cenu, rychlost i vypovídací hodnotu. Unit test prověří malou část kódu bez prohlížeče, API test ověří logiku přes rozhraní a end-to-end (E2E) test projde celou uživatelskou cestu. Kontrola přístupnosti hledá konkrétní bariéry a výkonnostní test potřebuje kontrolovanou zátěž i dostatečně podobné prostředí.
Pokud je tým vloží do jedné dlouhé úlohy, výsledek přijde pozdě a při selhání se obtížně hledá příčina. Pokud naopak při změně spouští jen několik rychlých kontrol, závažná chyba může zůstat skrytá až do releasu. Proto je nutné rozdělit testy podle rizika a okamžiku, ve kterém je výsledek ještě použitelný.
Praktická matice spouštění
Následující matice je výchozí bod, nikoli neměnné pravidlo. Kritická finanční operace může potřebovat přísnější kontrolu než obsahová stránka; malý monolit může mít jinou pipeline než soustava mikroslužeb.
Při pull requestu: co nejrychlejší zpětná vazba. Spusťte unit a komponentové testy, statické kontroly, relevantní API testy a malý balík UI smoke testů. Smoke test je krátká kontrola, zda fungují nejdůležitější cesty, například přihlášení a otevření objednávky. U změněných komponent lze přidat automatické kontroly přístupnosti. Cílem není dokázat, že je v pořádku celý systém, ale zastavit zjevnou regresní chybu ještě před sloučením kódu.
Po merge do hlavní větve: širší integrační kontrola. Přidejte úplnější sadu API a integračních testů, kritické E2E scénáře a kontroly přístupnosti důležitých stavů. Zde už lze ověřit sestavený artefakt, který je kandidátem na nasazení. Pokud je výsledek podmínkou další fáze, testy musí být dostatečně stabilní a vlastník pipeline musí vědět, jak selhání řešit.
Po nasazení: krátký test skutečně nasazeného prostředí. Post-deploy smoke test má potvrdit, že aplikace odpovídá, uživatel se přihlásí a jednu či dvě kritické cesty lze dokončit. V produkci používejte kontrolované účty a nedestruktivní scénáře nebo spolehlivý úklid dat. Neopakujte zde automaticky celou regresi: cílem je rychle odhalit chybu konfigurace, směrování, přístupových údajů nebo závislosti, která se v předchozím prostředí neprojevila.
V noci: šířka bez čekání vývojáře. Noční běh je vhodný pro rozsáhlejší E2E scénáře, více prohlížečů, větší matici oprávnění a širší automatické kontroly přístupnosti. Může obsahovat také scénáře závislé na pomalejších externích systémech. Výsledek však musí mít vlastníka a ranní způsob zpracování; dashboard plný dlouhodobě ignorovaných selhání není kontrola kvality.
Před releasem nebo kampaní: kontrola konkrétního rizika. Spusťte úplnou, podle rizika seřazenou regresi a scénáře spojené se změnou. Výkonnostní testy patří do samostatného, řízeného běhu s dohodnutým prostředím, zátěží a limity, nikoli mezi běžné UI testy na sdíleném CI runneru. Pokud potřebujete vybrat správný typ zátěže, pomůže srovnání load, stress, spike a soak testu.
Kam zařadit jednotlivé vrstvy
- Unit a komponentové testy mají tvořit nejrychlejší vrstvu a běžet při každé relevantní změně.
- API a integrační testy pokrývají byznys pravidla bez režie prohlížeče. Rychlou podmnožinu lze spouštět při pull requestu, širší po merge; praktické kontroly popisuje článek o testování REST API v CI/CD.
- UI/E2E testy si ponechte především pro klíčové cesty a místa, kde je nutná integrace celého systému. Před zařazením do pipeline odstraňte pevná čekání a závislost na společných datech.
- Automatické kontroly přístupnosti spouštějte nad konkrétními stavy – například otevřeným dialogem nebo chybou formuláře. Skener však nenahrazuje manuální posouzení; jeho hranice je třeba zohlednit ve strategii.
- Výkonnostní testy oddělte podle rizika: malý referenční test může sledovat regresi, kapacitní nebo stress test potřebuje samostatné podmínky a koordinaci.
Které selhání má zastavit pipeline
Blokovací pravidlo (quality gate) určuje podmínku, bez jejíhož splnění pipeline nepokračuje. Blokovat by měl důvěryhodný signál s jasným vlastníkem: neúspěšný unit test, porušený API kontrakt nebo selhání kritické cesty. Méně stabilní nebo informativní kontrola může zpočátku pouze upozornit, dokud tým neověří její spolehlivost a nedohodne způsob nápravy.
Nezaměňujte opakovaný pokus (retry) s opravou. Jedno automatické opakování může pomoci získat diagnostiku a rozlišit opakovatelné selhání od nestability. Pokud však test projde až na druhý pokus, výsledek je nutné označit a sledovat; nesmí se potichu tvářit jako čistý úspěch. U náhodných pádů nejprve rozlište chybu aplikace, testu a prostředí. Dočasná karanténa má mít vlastníka a termín opravy.
Diagnostika, paralelizace a bezpečnost
Při selhání uložte report, logy a údaje o verzi aplikace i prostředí. U UI testu pomůže snímek, video nebo trace, ale artefakty mohou obsahovat osobní údaje či tokeny; nastavte jim omezený přístup a přiměřenou dobu uchovávání. Oficiální návod pro Playwright v CI ukazuje spouštění při pushi, pull requestu i po nasazení a ukládání HTML reportu.
Nejprve testy izolujte tak, aby si navzájem neměnily data. Potom lze použít paralelní pracovní procesy (workery) nebo sharding – rozdělení sady mezi více CI úloh. Playwright podporuje sharding a sloučení reportů, vyšší počet workerů však není automaticky rychlejší: může přetížit testované prostředí nebo vytvořit konflikty ve společných účtech.
Hesla, API klíče a tokeny nevkládejte do repozitáře ani přímo do konfigurace. Použijte bezpečné úložiště přístupových údajů CI, samostatné účty s nejmenšími potřebnými oprávněními a maskování výstupu. Pravidla nastavte podle platformy, například pomocí GitHub Actions secrets nebo chráněných GitLab CI/CD variables.
Co tím získáte
Rozdělení testů podle rizika a okamžiku spuštění dává týmu rychlý signál při malé změně, širší jistotu před releasem a samostatné potvrzení po nasazení. Z výsledku je zároveň jasnější, která vrstva selhala a kdo má reagovat. Tým tak nemusí čekat na celou regresi u každého pull requestu ani ignorovat jednu dlouhou, často červenou úlohu.
Další krok
Sepište všechny existující testy, jejich trvání, stabilitu a riziko, které pokrývají. Z nich nejprve sestavte krátký pull-request balík a post-deploy smoke test, určete blokující pravidla a vlastníka selhání. Širší noční sadu a sadu před releasem přidávejte až tehdy, když z každé červené kontroly vede jasná cesta k diagnostice a rozhodnutí.