Proč testovat reducery a async akce bez běžícího serveru?

Nakonec si připravte záložní plán. I databáze s dobrou podporou může mít výpadek nebo se ukáže, že po nasazení do provozu nezvládá určité dotazy. Mějte proto možnost data exportovat a přenést jinam, a to v rozumném čase. Ověřte, zda existují nástroje pro migraci a zda je formát exportu otevřený. Tím se vyhnete situaci, kdy jste na jedné technologii závislí a nemůžete snadno odejít. Ověření podpory databáze není jednorázový úkol, ale průběžná kontrola, která se vyplatí při každé větší změně.

Redux se často testuje až v momentě, kdy je celá aplikace spuštěná a propojená s backendem. Jenže integrační prostředí je pomalé, nespolehlivé a odhalí chybu často pozdě. Reducer i async akci lze přitom otestovat izolovaně – stačí jim dodat správná data a zavolat je přímo. Výsledkem je rychlá zpětná vazba a jistota, že logika funguje nezávisle na serveru.

Kontrola odpovědi nestačí okem. Do záložky Tests napište krátké skripty, které ověří stavový kód, strukturu JSON nebo hodnotu pole. Například pm.test("status 200", () => pm.response.to.have.status(200)). Dále můžete měřit dobu odezvy nebo ukládat hodnoty z odpovědi do proměnných pro další požadavek. Tím vzniká řetězec, který simuluje reálný průchod aplikací. Pokud testy nepíšete, dříve nebo později přehlédnete regresi.

Nakonec počítej s tím, že první nabídka nemusí být vysněná. Pomůže i pozice v podpoře, na helpdesku nebo manuální testování jednoduchých změn. Každý měsíc, kdy něco skutečně testuješ, se počítá. Rozhoduje ochota učit se a doložitelná práce, ne délka života bez praxe.

Projekty s vlastním týmem nepadají na nedostatku schopností, ale na nedostatku hranic, rozhodnutí a průběžné kontroly. Kdo si tyto tři věci nastaví předem, mívá projekt hotový v rozumném čase i bez externí pomoci.

Izolované testy reducerů a thunků jsou rychlé, deterministické a odhalí chyby v logice dřív, než se dostanou do integrace. Nezastoupí test celého toku, ale výrazně zkrátí dobu hledání příčiny. Když reducer i async akce projdou samostatně, je mnohem snazší najít problém ve chvíli, kdy se spojí dohromady.

Async akce testujte přes thunk a fake dispatch Async akce v Reduxu bývá thunk – funkce, která dostane dispatch a getState. Testujete ji tak, že jí předáte vlastní dispatch, který si zaznamenává volání, a getState, který vrací připravený stav. Po zavolání await na návratovou hodnotu zkontrolujete, které akce byly odeslány a v jakém pořadí. Nepotřebujete žádné HTTP připojení, pokud síťovou vrstvu nahradíte atrapou.

Nakonec si hlídejte slovník. Slova jako „určitě", „garantuji" nebo „není problém" z odhadu dělají slib, i když to tak nemyslíte. Nahraďte je formulacemi „podle dnešních informací", „za těchto předpokladů" a „pokud se nic nezmění". Zákazník, který slyší podmínky, se ptá na rizika místo na datum. A to je přesně ten rozhovor, který vám oběma ušetří nejvíc problémů.

Praktický krok: zaveďte krátký týdenní stav, kde každý řekne, co dokončil, co ho blokuje a co potřebuje. Ne délku, ale konkrétní překážku. Pokud se stejná překážka objeví dvakrát, řešte ji jako systémový problém, ne jako osobní selhání. Dále je nutné ohlídat, aby se interní tým nerozpadl do příliš mnoha malých úkolů. Méně větších celků se dokončuje lépe než hromada drobností.

Pro ověření pořadí a počtu akcí se osvědčuje sbírat je do pole a porovnat celé pole najednou. Pokud test závisí na přesném tvaru payloadu, definujte si ho jako konstantu a používejte ji v testu i v produkčním kódu. Zamezíte tomu, aby se test rozbil jen kvůli přejmenování pole. U asynchronních testů nezapomeňte na await nebo vrácení promise – jinak test skončí dřív, než akce proběhne, a falešně projde.

Síťové volání nahraďte jednoduchým objektem s metodami, které vrací předpřipravené promise. Místo skutečného požadavku tak vrátíte úspěšnou odpověď, chybu i zpoždění. Testujte obě větve: úspěch i selhání. Typická chyba je testovat jen šťastnou cestu a zapomenout, že akce při chybě musí odeslat chybovou akci a nezanechat stav v nedokončeném stavu. Další častá chyba je Příliš mnoho mocků – pokud jich potřebujete deset, je lepší logiku rozdělit.

Rozdělení práce mezi vlastní tým zní lákavě: žádné faktury, žádné čekání na cizí lidi, všechno pod kontrolou. Jenže právě tady vzniká většina zpoždění. Nejde o to, že by interní lidé byli horší než externisté. Jde o to, že projekt s vlastním týmem nemá žádné přirozené hranice. Práce se rozplyne do běžného provozu a najednou není jasné, kdo co dělá a do kdy.

Kdy je interní tým past a kdy výhoda Vlastní tým má smysl tam, kde je potřeba hluboká znalost prostředí, dlouhodobá návaznost a rychlá reakce na změny. Naopak u jednorázových, jasně ohraničených úkolů často přináší víc režie než užitku. Pastí je i to, že se interní lidé bojí říct si o pomoc, protože nechtějí vypadat neschopně. Manažer proto musí aktivně zjišťovat, kde se práce zasekává, ne jen kontrolovat termíny.