5 návyků, které zvládnou testování dlouhých procesů na pozadí

Nejčastější problém je sdílený stav mezi testy. Fronta, databáze nebo dočasná složka se nevyčistí a druhý test vidí data z prvního. Před každým testem proto vytvářejte izolované prostředí – vlastní frontu, vlastní schéma nebo alespoň jednoznačný prefix klíčů. Nikdy nespoléhejte na to, že úloha na pozadí doběhne dřív než začne další test.

Kontrola před sloučením nemá být formalita. Malý Pull Request s jasným popisem, co a proč se mění, se kontroluje výrazně lépe než tisíc řádků najednou. Popište, jak změnu otestovat, a uveďte, čeho se týká. Recenzent by měl hledat logické chyby a dopady na okolí, ne přeformátované mezery. Pokud je změna velká, rozdělte ji. Autor nemá být jediný, kdo ji schvaluje, a nikdo by neměl sloučit vlastní práci bez pohledu druhého. Pokud se na něčem neshodnete, rozhodněte se podle toho, co je jednodušší udržovat, ne podle toho, kdo má silnější názor.

Pokud aplikace běží ve více instancích, paměťové úložiště přestane fungovat spolehlivě. Každý proces má vlastní počítadla a limit se tak fakticky násobí. Řešením je úložiště v Redis nebo jiné sdílené databázi. express-rate-limit podporuje vlastní store; stačí předat instanci klienta. Pozor na to, že Redis musí být dostupný a nesmí se stát dalším bodem selhání. Nastavte časové limity připojení a ošetřete výpadky tak, aby aplikace nespadla, ale aby limit přešel do bezpečného režimu.

Testování dlouho běžících procesů na pozadí se od testování běžných synchronních operací liší v jedné zásadní věci: výsledek nepřijde hned. Fronty, plánovače, dávkové úlohy nebo zpracování souborů běží minuty i hodiny a test, který jen zavolá metodu a čeká na odpověď, selže vždy. Řešením není prodlužovat časové limity, ale změnit přístup – testovat stav, do kterého proces postupně přechází.

Základem je popsat každý endpoint tak, aby se dal použít bez čtení zdrojového kódu. U každé operace uveďte metodu, cestu, očekávané parametry včetně typů a povinnosti, formát těla požadavku a strukturu odpovědi. Nestačí napsat, že vrací objekt. Napište, které klíče objekt obsahuje, co znamenají a jaké hodnoty mohou nabývat. Pokud se pole liší podle stavu, popište všechny varianty. Frontend pak nemusí hádat, proč mu jednou přijde číslo a podruhé řetězec.

Než začnete řešit větve a Pull Requesty, musíte se domluvit na jedné větvi, která je vždy nasaditelná. Říkejte jí klidně main nebo master, ale musí platit, že obsahuje jen to, co je otestované a připravené jít na produkci. Do této větve nikdo neposílá commity přímo. Každá změna jde přes novou větev a kontrolu. Pokud tohle není jasné, dřív nebo později se stane, že si dva lidé přepíší práci a dohledávání zabere celý den. Název pracovní větve by měl nést informaci: typ změny a krátký popis, například oprava-prihlaseni nebo nova-fakturace. Vyhněte se názvům typu test, vetev2 nebo jmeno-prijmeni.

Nakonec si nastavte ochranu hlavní větve: zakázané přímé zápisy, povinné schválení a povinné testy. Bez toho se dřív nebo později najde někdo, kdo si řekne, že to tentokrát stihne rychleji. Tato pravidla nejsou byrokracie, ale způsob, jak se k sobě chovat slušně. Tým, který je dodržuje, tráví méně času opravami a více času psaním kódu, který funguje.

Před sloučením vždy spusťte testy na aktuálním stavu hlavní linie, ne na tom, ze kterého jste vycházeli. Zkontrolujte, zda větev neobsahuje zapomenuté zakomentované bloky, dočasné výpisy do logu nebo soubory, které do repozitáře nepatří. Sloučení provádějte co nejdříve po dokončení funkce; odložený merge znamená, že se mezitím změní okolní kód a vyřešený konflikt se může vrátit v jiné podobě.

Aktualizace a řešení konfliktů bez zbytečného stresu Než začnete pracovat, aktualizujte svou větev o změny z main. Použijte rebase, pokud chcete čistou historii, nebo merge, pokud chcete zachovat kontext větvení. Obě varianty jsou správné, ale tým by měl zvolit jednu a držet se jí. Rebase na veřejně sdílené větvi nedělejte, přepisovali byste historii ostatním. Konflikty řešte lokálně, nikdy neposílejte větev s nevyřešenými značkami. Po vyřešení spusťte testy a build, ne jenže soubory vypadají dobře. Častá chyba je slepé přijetí jedné strany konfliktu bez pochopení, co druhá strana měnila. Když si nejste jistí, zavolejte kolegovi a projděte změnu spolu.

Zaveďte si pravidlo, že main je vždy zelený. Když se build nebo testy rozbijí, řeší se to okamžitě, ne až po dalším commitu. Kdo změnu způsobil, ten ji opraví nebo vrátí. Sloučení dělejte přes takzvaný squash jen tehdy, když chcete z mnoha drobných commitů jeden smysluplný celek. Jinak zachovejte jednotlivé commity, ale pište k nim jasné zprávy v rozkazovacím způsobu a s vysvětlením proč, ne jen co. Historie je pro lidi, kteří přijdou po vás.