Editing Testování redux reduktorů a asynchronních akcí bez integračního prostředí

Časté chyby, které vás připraví o smysl testů První typická chyba je testování implementace místo chování. Když testujete, že funkce volá jinou funkci s určitými argumenty, svazujete si ruce pro budoucí refaktoring. Test by měl selhat pouze tehdy, když se změní výsledek, ne když se změní vnitřní struktura kódu. Druhá častá chyba je psaní testů, které projdou i bez testované funkce. Typicky jde o testy, které kontrolují jen to, že funkce nevyhodí výjimku, ale nekontrolují návratovou hodnotu. Takový test je k ničemu.<br><br>Pro lepší izolaci můžete využít knihovny jako Redux Mock Store, které vám poskytnou jednoduché rozhraní pro testování akcí a thunků. Nemusíte ale hned sahat po dalších závislostech – stačí vám obyčejný objekt s metodami. Testy pak budou rychlé, deterministické a snadno udržovatelné. Tento přístup se hodí i pro projekty, kde nechcete zatěžovat build dalšími balíčky.<br><br>Když se řekne REST API v Node.js, většina vývojářů sáhne po frameworku Express. Není to náhoda – Express je minimalistický, dobře zdokumentovaný a díky své flexibilitě vám umožní postavit API přesně podle potřeb. Než ale začnete psát první endpoint, ujasněte si, co vlastně chcete, aby vaše API dělalo. Bez jasné definice zdrojů a jejich vztahů snadno skončíte u nepřehledného kódu, který se bude těžko udržovat.<br><br>Typickou chybou je spoléhat na skutečné API volání nebo na globální store. Takový test je pomalý a náchylný na selhání z důvodu síťových výpadků. Další častou chybou je zapomenout na asynchronní povahu thunku – test skončí dřív, než thunk stihne dokončit. Řešením je použít async/await nebo zpětné volání, které počká na dokončení. V neposlední řadě se vyvarujte testování reducerů přes store – to je integrační test, který nepotřebujete pro pokrytí čisté logiky.<br><br>Nejčastější chyby při odhadování času Jednou z nejrozšířenějších chyb je ignorování režie – schůzky, e-maily, code review, testování, nasazení nebo ladění. Zkušený vývojář často stráví jen polovinu pracovní doby samotným psaním kódu. Pokud tuto režii nezapočítáte, bude váš odhad systematicky nízký. Doporučuji přidat k čistému odhadu rezervu alespoň 20–30 %, a to nejen na režii, ale i na chyby, které se objeví až během integrace.<br><br>Dalším častým problémem je odhadování „ve vzduchu" bez znalosti existujícího kódu. Pokud neznáte architekturu, použité knihovny nebo kvalitu testů, je váš odhad jen tipování. Před odhadem si projděte relevantní části kódu, podívejte se na podobné úkoly z minulosti a zjistěte, jak dlouho reálně trvaly. Historická data z vašeho týmu jsou nejcennějším zdrojem – pokud je nemáte, začněte si je zaznamenávat.<br><br>Třetí oblastí je automatizace webových úkonů, ale ne ve smyslu procházení stránek proti pravidlům. Můžete si například napsat skript, který se přihlásí na váš účet, stáhne potřebná data a uloží je do souboru. Tady ale platí přísné pravidlo: vždy respektujte podmínky použití dané služby a mějte na paměti, že nadměrné automatické dotazy mohou vést k zablokování vaší IP adresy. Dobré je zahrnout do skriptu prodlevy mezi jednotlivými požadavky, abyste server zbytečně nezatěžovali.<br><br>Jak namockovat asynchronní závislosti a ověřit volání Při testování thunků se často setkáte s nutností ověřit, že akce byly dispatchovány ve správném pořadí. Použijte pole, do kterého zaznamenáváte volání dispatch. Po provedení thunku porovnáte obsah pole s očekávanou sekvencí. Pokud thunk používá getState, vraťte z ní předpřipravený objekt stavu. Vyhněte se testování více thunků najednou – každý test by měl být izolovaný, aby byl snadno identifikovatelný problém.<br><br>Nezapomínejte ani na bezpečnostní nástroje, jako je Find Usages nebo Go to Declaration. Tyto funkce vám pomohou rychle zjistit, kde všude se daný kód používá, a to dříve, než začnete s úpravami. Často se stává, že při ručním refaktorování přehlédnete některé volání – vestavěné nástroje vám ukáží kompletní seznam a vy se vyhnete nepříjemným překvapením. Pokud si nejste jisti, použijte před větším zásahem verzování a porovnejte rozdíly.<br><br>Pokud jde o strukturu projektu, neházejte všechno do jednoho souboru. Rozdělte kód na moduly – oddělte routes, controllers a služby pro práci s daty. Tím získáte přehlednost a usnadníte si testování. Pro menší API stačí i tři soubory, ale pro větší projekty je dobré zavést složkovou strukturu. Důležité je taky myslet na CORS – pokud vaše API budou volat prohlížeče z jiné domény, musíte povolit příslušné hlavičky, jinak požadavky skončí chybou.<br><br>Jak efektivně využít další funkce pro úpravu struktury kódu Kromě přejmenování se vyplatí používat nástroje pro extrakci metod. Pokud narazíte na příliš dlouhou funkci, označte blok kódu a zvolte akci Extract Method. IDE samo navrhne parametry a návratovou hodnotu, čímž eliminuje chyby při ručním sestavování signatury. Podobně můžete extrahovat proměnné, konstanty nebo celé třídy. Tímto způsobem získáte čistší strukturu bez zbytečného opisování.