Co musí obsahovat repozitář, aby licence dávala smysl?

Poslední věc, která rozhoduje o tom, jestli vám nástroje ušetří čas, je konzistence. Když si zkratky nastavíte jednou a budete je používat každý den, přestanete nad refaktoringem přemýšlet a začnete ho dělat průběžně. Průběžné malé úpravy bolí méně než jednorázové velké čištění. Začněte dnes třemi zkratkami a do týdne poznáte rozdíl v tom, kolik času vám zbývá na skutečnou práci.

Testovací pyramida vznikala v době, kdy se požadavky měnily pomalu a vydání jednou za čtvrt roku bylo normální. Dnes se ale rozsah funkcí upravuje průběžně, priority se přesouvají a to, co bylo minulý měsíc kritické, může být dnes zbytečné. Pokud na to pyramida nereaguje, začne pokrývat něco jiného, než tým skutečně potřebuje. Řešení není pyramida zrušit, ale nastavit pravidla, podle kterých se její vrstvy posouvají spolu s požadavky.

U operací, které mění více zdrojů, je potřeba idempotentní klíč kombinovat s optimistickým zamykáním. Například při převodu peněz se kontroluje verze zůstatku. Bez toho může i idempotentní klíč selhat, pokud se mezitím změnil stav. U dlouhých operací se vyplatí oddělit přijetí požadavku od jeho provedení. Server vrátí identifikátor úlohy a klient se dotazuje na stav. Opakované vytvoření úlohy se stejným klíčem vrátí stejný identifikátor.

U asynchronních testů platí dvě pravidla. Vždy vrať slib z testu, aby ho runner počkal. A vždy ošetři obě větve – úspěch i chybu. Typická chyba je testovat jen stav po dokončení, ale ne to, co se stalo během čekání. Ověř, že se dispatch volá ve správném okamžiku a že se po chybě neposílá akce pro úspěch. Pokud používáš thunk, testuj ho jako obyčejnou funkci; žádný store k tomu nepotřebuješ.

Jazyk a architektura: co si vybrat na začát

Pro složitější scénáře se vyplatí testovat selektory zvlášť. Selektory jsou také čisté funkce a jejich testování je nejrychlejší část sady. Když reducer i selektor pokryješ izolovaně, integrační testy pak řeší jen propojení, ne logiku. To výrazně zkrátí dobu běhu a usnadní hledání chyby.

Asynchronní akce bez serveru Async akce nejsou nic jiného než funkce, které postupně volají dispatch. K jejich testování nepotřebuješ běžící backend. Stačí vytvořit falešný dispatch a falešnou funkci, která vrací slib. Zavolej thunk s těmito závislostmi a ověř, které akce byly odeslány a v jakém pořadí. Pokud thunk používá axios nebo fetch přímo v těle, bude se testovat obtížně. Řešením je předat klienta jako argument nebo použít injektáž závislostí.

Kde se licence ztrácí a jak tomu předejít Licence se ztrácí ve chvíli, kdy ji vývojář přidá, ale zapomene na ni upozornit v README. Uživatel otevře repozitář, vidí kód, ale nemá jistotu, za jakých podmínek ho smí použít. Do README proto napiš krátkou větu s názvem licence a odkazem na soubor LICENSE. Zároveň zkontroluj, zda licence odpovídá závislostem. Pokud projekt používá knihovnu pod copyleftovou licencí, může to ovlivnit, jakou licenci můžeš zvolit pro celek. Nestačí zkopírovat cizí licenční soubor bez ověření, že sedí na tvůj případ.

Test reduceru začni tím, že zavoláš funkci se dvěma argumenty: výchozím stavem a akcí. Porovnej výsledek pomocí hluboké rovnosti. Nezapomeň testovat i neznámou akci – reducer musí vrátit původní stav, ne undefined. Častá chyba je mutace: vývojář upraví pole přes push a test projde, protože stejná reference zůstane. Proto po každém testu ověř, že se původní objekt nezměnil, ideálně tak, že si před voláním uložíš kopii a porovnáš ji.

Nakonec si dej pozor na dvě věci. Nesnaž se testovat implementační detaily, jako je počet volání dispatch, pokud to není součástí kontraktu. A nepodceňuj testy chybových stavů – právě tam vzniká většina regresí. Když reducer i async akce pokryješ bez serveru, získáte rychlou a spolehlivou sadu, která odhalí chybu dřív, než se dostane do integrace.

Redux je navržený tak, že většinu logiky lze ověřit bez jakéhokoli integračního prostředí. Reducer je čistá funkce: dostane stav a akci, vrátí nový stav. Žádné API, žádná databáze, žádný prohlížeč. Pokud tomu tak není, problém není v testech, ale v návrhu. Prvním krokem je proto rozdělit kód na dvě části: čistou logiku přechodů stavů a vedlejší efekty, které patří do middlewaru nebo thunků.

Soubor s licencí patří do kořene repozitáře, nikoli do podsložky nebo do dokumentace. Použij standardní název, obvykle LICENSE nebo LICENSE.txt, případně s příponou podle formátu. Obsah musí být úplné znění licence, ne jen odkaz na ni. Pokud použiješ zkrácenou verzi, někteří uživatelé ji nebudou považovat za platnou. Velmi častou chybou je vložit licenci pouze do komentáře v hlavním souboru zdrojového kódu – tam ji přehlédne každý, kdo prochází strukturu projektu.