Regrese — co to je, proč vzniká a jak testovat

Co je regrese ve vývoji

Regrese — je situace, kdy funkčnost, která fungovala v předchozí verzi, přestane fungovat po provedení změn. Změna může být jakákoli: oprava chyby, přidání nové funkce, refaktorování, aktualizace knihovny nebo dokonce změna konfigurace. Regrese je hlavním nepřítelem stability: každá změna riskuje rozbití něčeho, co již bylo zkontrolováno a vydáno.

Termín pochází z testování: regresní testování — je opětovné spuštění existujících testů po každé změně. Pokud dříve procházející test selže — došlo k regresi. V širším smyslu není regrese jen selhání testu, ale také jakékoli zhoršení chování zaznamenané uživatelem nebo QA. Podle Tricentis State of Testing 2023 tvoří regrese 35–45 % všech chyb nalezených v produkci.

Regrese se od běžné chyby liší časovým kontextem: chyba mohla existovat vždy, zatímco regrese je vždy výsledkem změny. To je důležitý rozdíl, protože hledání příčiny regrese začíná analýzou změn: co se změnilo mezi „fungovalo“ a „přestalo fungovat“. Git bisect — standardní nástroj pro nalezení commitu, který způsobil regresi.

Typy regresí a příklady

Lokální regrese — změna v modulu A rozbíjí funkčnost ve stejném modulu A. Příklad: vývojář přepíše funkci řazení a ta přestane správně zpracovávat prázdné pole. Lokální regrese je nejjednodušší na odhalení a opravu, protože příčina a následek jsou blízko sebe.

Vzdálená regrese — změna v modulu A rozbíjí funkčnost v modulu B, který není přímo propojen kódem, ale je propojen daty nebo časem. Příklad: změna schématu databáze v modulu „Uživatelé“ rozbije report v modulu „Analytika“, který používá stejnou tabulku. Vzdálené regrese jsou nejzákeřnější: vývojář netuší, že jeho změna ovlivní jiný modul.

Regrese vedlejších účinků — změna vedlejšího účinku (logování, ukládání do mezipaměti, odesílání notifikací) rozbíjí očekávané chování. Příklad: vývojář přidal ukládání do mezipaměti pro zrychlení, ale kvůli zastaralé cache uživatelé vidí stará data. Regrese vedlejších účinků se těžko chytají automatickými testy, protože vedlejší účinky často nejsou testy pokryty.

Výkonnostní regrese — kód nadále funguje správně funkčně, ale pomaleji než dříve. Příklad: nový šifrovací algoritmus dává stejné výsledky, ale doba provádění vzrostla z 2 ms na 200 ms. Výkonnostní regrese nejsou zachyceny běžnými unit testy — jsou potřeba benchmarky a profilování.

Proč regrese vznikají

První příčina — propojení kódu (coupling). Čím silněji jsou moduly na sobě závislé, tím vyšší je pravděpodobnost, že změna v jednom způsobí regresi v druhém. Klasické antipatterny: God Object (objekt, který dělá všechno), Shotgun Surgery (změna jednoho vyžaduje úpravy na desítkách míst), Circular Dependency. Snížení coupling — úkol architektury: principy SOLID, Dependency Injection, hexagonální architektura.

Druhá příčina — nedostatek testů pro měněnou funkčnost. Pokud kód není pokryt testy, vývojář se o regresi dozví až od QA nebo uživatelů. Podle Google Testing Blog mají projekty s pokrytím testů >75 % 5krát méně regresí než projekty s pokrytím <25 %. TDD (Test-Driven Development) zaručuje, že testy jsou napsány před kódem, ne „až bude čas“.

Třetí příčina — lidský faktor. Vývojář neví o existenci sousední funkčnosti, nerozumí všem závislostem nebo prostě spěchá. Příčina — nedostatečné sdílení znalostí o kódové bázi. Řešení: code review s účastí vývojářů z jiných modulů, pair programming, dokumentace architektury. Bus factor projektu je nepřímo úměrný počtu zdokumentovaných architektonických rozhodnutí.

Regresní testování a jeho role

Regresní testování — je proces opětovného spouštění existujících testů po každé změně za účelem ověření, že stará funkčnost nebyla rozbita. Je to jediný způsob, jak zaručit, že nová změna nenarušila fungování stávajícího kódu. Bez regresního testování je každé vydání loterií: vývojář doufá, že nic nerozbil, ale nemůže to potvrdit.

Ruční regresní testování — nejdražší a nejneefektivnější přístup. S růstem projektu roste počet regresních testovacích scénářů lineárně a čas na jejich ruční provedení exponenciálně. Po 2–3 letech vývoje může ruční provedení regrese trvat 2–3 týdny, což znemožňuje častá vydání. Jediným východiskem je automatizace.

Automatizované regresní testování se dělí na úrovně podle testovací pyramidy:

• Unit testy — rychlé, izolované, pokrývají jednotlivé funkce a metody
• Integrační testy — ověřují interakci mezi moduly, DB, externími službami
• E2E testy — ověřují kompletní uživatelské scénáře přes UI nebo API
• Snapshot testy — porovnávají aktuální výstup komponenty s referenčním

Podle Google Testing Blog je optimální poměr: 70 % unit testů, 20 % integračních, 10 % E2E. Odchylka od tohoto poměru snižuje účinnost regresního testování: nadbytek E2E testů zpomaluje pipeline, nedostatek unit testů nechává mikrochyby bez povšimnutí.

Strategie automatizace regresního testování

První strategie — Full Regression. Spouštějí se všechny testy projektu. Nejspolehlivější, ale také nejpomalejší přístup. Použitelný pro malé projekty (do 10 000 testů, doba běhu <30 minut). U velkých projektů může plná regrese trvat hodiny, což činí CI/CD pipeline nepraktickým.

Druhá strategie — Selective Regression. Spouštějí se pouze testy související se změněným kódem. Pro určení souvislostí se používá graf závislostí kódu. Nástroje: Bazel (Google), Nx (JavaScript), sbt (Scala). Selective regression šetří 60–80 % času běhu, ale vyžaduje přesné sestavení grafu závislostí — chyby vedou k vynechaným regresím.

Třetí strategie — Prioritized Regression. Všechny testy jsou seřazeny podle priority: critical path (nejdůležitější uživatelské scénáře), high risk (kód s historií chyb), changed code (kód ovlivněný změnou). Nejdříve se spouštějí nejprioritnější testy — pokud projdou, vývojář dostává rychlou zpětnou vazbu. Časově omezené spuštění: během 10 minut se zkontrolují kritické testy, zbytek — na pozadí.

Jak předcházet regresím v projektu

První a nejdůležitější krok — kultura psaní testů. Každou změnu by měl doprovázet test, který ověřuje, že změna funguje, a test, který ověřuje, že se nic nerozbilo. TDD (Test-Driven Development) dává nejlepší výsledky: vývojář nejprve napíše padající test, poté kód, který ho úspěšně provede. To zaručuje, že test existuje před kódem.

Druhý krok — CI/CD pipeline s povinným spouštěním testů. Pull request nelze sloučit, dokud neprojdou všechny testy. Testy nelze „přeskočit“ kvůli naléhavosti — naléhavé změny procházejí zrychlenou, ale povinnou sadou testů. Podle Google DevOps Research mají týmy s povinným CI/CD 3krát méně regresí v produkci.

Třetí krok — monitoring v produkci. Ani ty nejlepší testy nezaručují 100% ochranu před regresemi. Nástroje observability (Sentry, Datadog, New Relic) by měly sledovat klíčové metriky po každém nasazení: chybovost, latenci, propustnost. Automatické vrácení zpět (rollback) při překročení prahů — bezpečnostní polštář, pokud se regrese přece jen dostane do produkce.

Čtvrtý krok — code review s regresním myšlením. Recenzent by si měl položit otázku: „Které další moduly by tato změna mohla rozbít?“. Nestačí zkontrolovat, že kód je správný — je třeba zkontrolovat, že nenaruší sousední funkčnost. Kontrolní seznam pro code review by měl obsahovat bod „kontrola regresí v sousedních modulech“.