Testy reducerů a thunků zvládnete i bez běžícího prohlížeče

Neignorujte chybová hlášení. Podrobná chybová zpráva z databáze prozradí názvy tabulek, sloupců i typy dat a útočníkovi výrazně usnadní další postup. V produkčním prostředí proto zapněte obecné chybové stránky a podrobnosti logujte pouze na server. Totéž platí pro ladící nástroje, které nesmí být veřejně dostupné.

Základní test vypadá tak, že zavoláte reducer s výchozím stavem a akcí a porovnáte výsledek s očekávaným objektem. Nepište testy tak, že jen zkontrolujete, že se stav změnil. Zkontrolujte konkrétní pole, jejich hodnoty a to, že ostatní části stavu zůstaly nedotčené. Častá chyba je sdílený výchozí stav mezi testy: pokud ho reducer mutuje, jeden test ovlivní druhý. Vždy vytvářejte čistou kopii stavu před každým testem, ideálně pomocí tovární funkce.

Před podpisem smlouvy si zjisti, jak vypadá běžný den. Na pohovoru se ptej, kdo bude tvůj mentor, jak často probíhá code review a jestli se testy píšou před nebo po nasazení. Slušná odpověď zní konkrétně: jméno, frekvence, nástroj. Vyhýbavé „nějak to řešíme" znamená, že to neřeší. Stejně důležité je zjistit, jestli tým používá verzovací systém a jak řeší konflikty větví. Pokud ne, budeš trávit čas ručním kopírováním souborů.

Nejčastější past je testování thunků přes skutečný store. Store vytváří vedlejší efekty, drží stav mezi testy a nutí vás řešit middleware. Pro izolovaný test stačí obyčejná funkce dispatch, která volání ukládá do pole. Další chyba je zapomenutý return u thunku. Pokud thunk nevrací promise, test skončí dřív, než async akce doběhne, a vy dostanete falešně zelený výsledek. Vždy vracejte promise a v testu na něj čekejte.

Práce ve větvi je bezpečná jen tehdy, když víš, kde jsi. git branch vypíše větve, git switch -c nova-vetev vytvoří a přepne. Častá chyba: upravovat soubory, pak přepnout větev a divit se, že změny „zmizely". Git je nemaže, jen je nechá v pracovním adresáři a přepnutí buď zablokuje, nebo je přenese jinam. Před přepnutím buď změny commitni, nebo je odlož pomocí git stash. Sloučení (git merge) přináší konflikty — nejsou porucha, jsou normální stav. Otevři označené soubory, vyber správnou verzi, odstraň značky >>>>>>, pak soubor přidej a commit dokonči.

Async akce testujte přes falešný dispatch a injektovaný klient Asynchronní akce nejsou čisté, protože komunikují s okolím. Klíčem je izolovat to okolí. Místo skutečného HTTP klienta předáte akci objekt s metodou, kterou v testu nahradíte. Akce by měla klienta dostat jako argument nebo přes thunk extra argument, ne ho importovat přímo. Pak v testu vytvoříte falešného klienta, jehož metoda vrací předpřipravený promise, a zachytíte všechny dispatch volání do pole. Po dokončení akce zkontrolujete pořadí a obsah dispatch volání.

Než uděláte první potvrzení změn, založte soubor, který vyjmenuje ignorované cesty. Bez něj se do historie dostanou tisíce souborů z knihoven a každá změna závislosti zaplaví rozdíly, ve kterých se nedá nic najít. Stejně důležité je nastavit jméno a e-mail, protože podle nich se přiřazují jednotlivé změny. Pak teprve inicializujte repozitář a přidejte první dávku souborů. Kontrolujte, co se chystá k uložení, a to ještě před samotným potvrzením.

Pozor na dvě věci, které lidi pletou. Za prvé, vysoké pokrytí neznamená kvalitu. Můžete mít devadesát procent a přesto propouštět chyby do produkce. Za druhé, nízké pokrytí nemusí být problém, pokud jde o kód, který se nemění a je triviální. Rozhodujte podle rizika, ne podle čísla v přehledu.

Pokrytí kódu testy se často bere jako univerzální metrika kvality. Jenže číslo samo o sobě nic neříká o tom, zda testy skutečně odhalují chyby. Tým, který honí stovku procent, často píše testy, jež procházejí, ale nic netestují. První krok je přestat se ptát „kolik procent máme" a začít se ptát „co nám ty testy skutečně zachytí".

U async akcí se vyplatí testovat tři scénáře: úspěch, chybu a okamžik před dokončením. U úspěchu ověřte, že se nejdřív odešle akce o zahájení a pak akce s daty. U chyby zkontrolujte, že se odešle akce s chybou a že se nezavolá úspěšná větev. U zpožděné odpovědi ověřte, že se stav nemění, dokud promise nedoběhne. Nepoužívejte pevné časovače typu setTimeout v testech, pokud to jde; místo toho použijte promise a čekejte na jeho vyřešení.

Reducery jsou čisté funkce. To je jejich největší výhoda při testování: na vstupu dostanou stav a akci, na výstupu vrátí nový stav. Nepotřebujete k tomu žádné integrační prostředí, server ani prohlížeč. Stačí testovací runner, který umí spouštět JavaScript, a knihovna pro aserce. Pokud reducer zapisuje do globálního stavu, sahá na Date.now() nebo na Math.random(), přestává být čistý a testy začnou být křehké. Takové závislosti vytáhněte do parametrů akce nebo je obalte vlastním modulem, který v testu nahradíte.