Praktickým nástrojem je tzv. „buffer" (rezerva). Do odhadu zahrňte tři úrovně rezervy: na chyby, na komunikaci a na změny požadavků. Například odhad čistého času 10 hodin: přidáte 20 % na chyby, 15 % na komunikaci a 10 % na změny. Výsledek: 10 + 2 + 1,5 + 1 = 14,5 hodiny. Rezerva není zbytečná – je to poctivý odhad rizik. Klient nebo vedení by měli vědět, že tato rezerva je součástí odhadu, a ne položkou navíc.<br>
<br>
<br>
<br>
Při práci s více prostředími (development, staging, produkce) doporučuji vytvořit si samostatné workflow pro každé prostředí nebo použít kontexty. Pomocí environment protection rules můžete omezit, kdo má právo nasazovat do produkce. To je užitečné zejména v týmech, kde chcete mít kontrolu nad tím, kdo spouští citlivé deploye. Nezapomeňte také na konfiguraci concurrency – pokud spustíte dvě nasazení současně, může dojít ke konfliktu. Nastavte si zrušení běhu při novém pushi do stejné větve.<br>
<br>
<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>
<br>
<br>
Asynchronní akce testujete podobně, ale s jedním rozdílem: potřebujete simulovaný dispatch a getState. Předpokládejme thunk, který načítá data z API a po úspěchu dispatchuje akci. V testu vytvoříte mock funkce pro dispatch a getState, zavoláte thunk a počkáte na dokončení. Klíčové je správně nastavit mock pro API volání – ideálně pomocí vstřikování závislostí, kdy thunk přijímá funkci pro fetch jako parametr. Tím zajistíte, že test nezávisí na síti, a můžete simulovat úspěch i chybu.<br>
<br>
<br>
<br>
Testování Redux logiky nemusí vždy znamenat zapojení celé aplikace. Reducery jsou čisté funkce, což je činí ideálními pro jednotkové testy v izolaci. Asynchronní akce (například s Redux Thunk) lze testovat podobně, pokud správně namockujete závislosti. Tento článek ukazuje, jak na to bez spouštění celého integračního prostředí, tedy rychle a spolehlivě.<br>
<br>
<br>
<br>
<span style="font-weight: 800;">Pro testování reducerů</span> stačí volat je s aktuálním stavem a akcí. Vezměte si příklad jednoduchého reduktoru pro seznam úkolů. V testu vytvoříte počáteční stav, zavoláte reducer s akcí typu 'ADD_TODO' a ověříte, že nový stav obsahuje přidanou položku. Důležité je netestovat vnitřní implementaci, ale výsledný stav. Vyhnete se tím zbytečným změnám testů při refaktoru. Pro hlubší ověření použijte knihovnu jako Jest, která umožňuje snapshot testování, ale pozor na příliš velké snapshosty – mohou být nepřehledné a křehké.<br>
<br>
<br>
<br>
Začněte tím, že si rozdělíte závislosti na tři skupiny: stabilní knihovny s dlouhodobou podporou, aktivně vyvíjené knihovny a interní moduly. U první skupiny používejte striktní verzování, tedy přesné číslo verze bez wildcardů. U druhé skupiny si definujte rozsah, který povoluje menší aktualizace, ale ne zásadní změny rozhraní. Třetí skupinu, interní moduly, spravujte jako samostatné projekty s vlastním číslem verze a zveřejňujte je do lokálního úložiště. Tím získáte přehled, která verze čeho je v sestavení použita.<br>
<br>
<br>
<br>
Nejprve si vyberte jedno jednoduché veřejné API, které vás zajímá – třeba pro počasí, kurzy měn nebo seznam států. K tomu budete potřebovat nástroj pro testování požadavků, jako je nástroj příkazové řádky nebo grafický klient. Klíčové je naučit se číst dokumentaci. Každé API má popis koncových bodů (adres, na které se posílají požadavky), povolené metody (GET, POST, PUT, DELETE) a parametry. Vyzkoušejte si nejprve GET požadavek, který pouze získává data – je nejbezpečnější a nezpůsobí žádné změny.<br>
<br>
<br>
<br>
Nakonec pamatujte, že verzování není jen o číslech, ale o komunikaci. Nezavádějte příliš mnoho verzí najednou. Pokud je to možné, udržujte jednu hlavní verzi knihovny a pro starší verze vytvářejte jen bezpečnostní opravy. U projektů s více verzemi knihoven pak vždy definujte, která verze je oficiální pro produkci a která je určena pro experimenty. Tím se vyhnete zmatkům a všichni budou vědět, na čem staví.<br>
<br>
<br>
<br>
Základní pipeline začíná souborem, který definuje událost spouštějící workflow. Nejčastěji používáte push do větve main nebo pull request. Důležité je omezit spouštění na relevantní větve, jinak se pipeline spustí při každém pushi do libovolné větve, což zbytečně zatěžuje běhy. Dobrým zvykem je přidat filtr na cesty – pokud změníte pouze dokumentaci, nemá smysl spouštět celý build. Využijte klíčové slovo paths a paths-ignore pro efektivní řízení spouštění.
