Když po roce zjistíš, že se neposouváš, nečekej na zázrak. Promluv si s vedoucím, navrhni konkrétní změnu: pravidelné review, jiný projekt, stínování zkušenějšího kolegy. Pokud se nic nezmění do dvou měsíců, začni se dívat jinam. První práce není manželství. Je to místo, kde si stavíš základy. A základy se mají stavět tam, kde ti někdo ukáže, jak se to dělá.
Pro síťové volání použijte stub nebo mock. Nahraďte funkci, která volá API, za jednoduchou funkci, která vrací Promise.resolve s předpřipravenými daty. Stejně tak otestujte chybovou větev: Promise.reject s chybou. Po zavolání async akce počkejte na dokončení Promise. To je místo, kde lidé chybují nejčastěji: zapomenou na await nebo na vrácení Promise z testu. Testovací runner pak skončí dřív, než se akce dokončí, a vy dostanete falešně pozitivní výsledek.
Základní volba stojí mezi jedním sdíleným repozitářem a více repozitáři s centrální konfigurací. Sdílený repozitář znamená, že všechny části projektu leží pohromadě a konfigurační soubory jsou na jednom místě. Výhodou je okamžitá viditelnost změn a jednodušší zavádění nových členů týmu. Nevýhodou je horší izolace: změna v jedné části může nechtěně ovlivnit jinou a nástroje musejí zvládat větší objem dat. U více repozitářů je potřeba vyřešit, odkud se konfigurace bere a jak se synchronizuje.
Async akce testujte přes middleware a fake dispatch Asynchronní akce nejsou čisté funkce, ale i tak je lze testovat bez sítě. Nejprve si ujasněte, co vaše async akce dělá: obvykle vrací funkci, která přijímá dispatch a getState. Tuto funkci zavoláte ručně s fake dispatch a fake getState. Fake dispatch je jen pole, do kterého ukládáte všechny akce, které byly odeslány. Fake getState vrátí předpřipravený stav. Tím simulujete prostředí Reduxu bez storeu.
Pro zpětnou dohledatelnost je klíčové, aby každý commit řešil jednu věc. Když smícháte opravu chyby, refaktoring a novou funkci, zpráva bude nutně vágní. Rozdělte práci na menší celky. U rozsáhlejších změn napište do zprávy, co změna nahrazuje a jaké důsledky má pro zbytek kódu. Uveďte, pokud možno, i to, co jste záměrně neudělali – předejdete tak pozdějším otázkám.
End-to-end testy mají nejmenší zastoupení, obvykle 5–10 %. Ověřují kritické scénáře z pohledu uživatele: přihlášení, dokončení objednávky, odeslání formuláře. Jsou pomalé a křehké, protože závisí na prohlížeči, síti i datech. Typická chyba je psát end-to-end testy pro každou novou funkci. Mnohem lepší je pokrýt jimi jen to, co nelze spolehlivě ověřit níže. Každý takový test by měl mít jasný důvod existence a měl by být součástí CI, ale ne na úkor rychlosti zpětné vazby.
Pište zprávu tak, jako by ji četl někdo jiný První řádek je nejdůležitější. Musí být krátký, konkrétní a veškerém čase. Vyhněte se slovům jako „různé", „opravy", „úpravy" nebo „vylepšení". Místo „oprava chyby" napište „oprava pádu při načítání prázdného seznamu". Místo „úprava" napište „přesun validace e-mailu do samostatné funkce". Pokud první řádek nestačí, přidejte za prázdný řádek podrobnější vysvětlení – klidně v odrážkách, ale vždy s kontextem.
Nakonec platí, že sjednocení není jednorázový úkol, ale dohoda, kterou je potřeba udržovat. Vyberte variantu, která odpovídá velikosti týmu a počtu projektů, a nechte si prostor pro změnu, až se podmínky vyvinou. Jednotná konfigurace má smysl jen tehdy, když zjednodušuje každodenní práci, ne když přidává další vrstvu, kterou je třeba hlídat.
Začněte tím, že reducer otestujete na neznámou akci. Zavolejte ho s undefined stavem a akcí, kterou nezná. Musí vrátit výchozí stav. To je první past: mnoho lidí zapomene, že reducer nesmí vracet undefined, protože by to rozbilo kombinaci s dalšími reducery. Druhá častá chyba je mutace stavu. Otestujte, že původní objekt zůstal nezměněn. Porovnejte reference nebo použijte mělkou kopii a zkontrolujte, že se nezměnila. Testy bez integrace vás donutí psát reducer jako čistou funkci, což je přesně to, co potřebujete.
Typická chyba je psát zprávu v minulém čase a v trpném rodě. „Bylo opraveno" nic neříká. Pište v rozkazovacím způsobu nebo v přítomném čase: „opravuje pád", „přidává logování". Další častá chyba je odkazovat na čísla ticketů bez vysvětlení. Číslo je užitečné, ale samo o sobě nestačí. Pokud někdo nemá přístup do systému, musí z commit zprávy pochopit, o co šlo.
Typická chyba je také testovat příliš mnoho najednou. Netestujte, že se správně zavolalo API, že se správně aktualizoval store a že se správně vykreslila komponenta. To už je integrace. Držte se jedné věci: async akce má odeslat správné akce ve správném pořadí. Zkontrolujte, že první akce je typ „pending" nebo podobná, pak že následuje úspěch nebo chyba. Pořadí je důležité, protože na něm závisí UI.