https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=Margarito2965 2026-10-13T21:48:05Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/index.php?title=Testy_reducer%C5%AF_a_thunk%C5%AF_zvl%C3%A1dnete_i_bez_b%C4%9B%C5%BE%C3%ADc%C3%ADho_prohl%C3%AD%C5%BEe%C4%8De&diff=401547 2026-10-01T19:15:43Z

<p>Margarito2965: </p> <hr /> <div>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é.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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&quot; 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ů.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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&quot;. 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 &gt;&gt;&gt;&gt;&gt;&gt;, pak soubor přidej a commit dokonči.&lt;br&gt;&lt;br&gt;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í.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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&quot; a začít se ptát „co nám ty testy skutečně zachytí&quot;.&lt;br&gt;&lt;br&gt;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í.&lt;br&gt;&lt;br&gt;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.</div>

Margarito2965 https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:Margarito2965&diff=401546 2026-10-01T19:15:41Z

<p>Margarito2965: Die Seite wurde neu angelegt: „Někdo, kdo světem interiérů žije už dlouho. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejvíc mě baví popisovat postupy krok za krokem.“</p> <hr /> <div>Někdo, kdo světem interiérů žije už dlouho. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejvíc mě baví popisovat postupy krok za krokem.</div>

Margarito2965