Editing Jak dostat z retrospektivy víc: strukturovaná zpětná vazba

Nakonec si osvojte pravidlo: testy by měly být rychlé a izolované. Pokud potřebujete ke spuštění testu databázi nebo síť, děláte to špatně. Vše, co je externí, nahraďte mockem. Tím zajistíte, že testy poběží v řádu sekund a budou spolehlivé. Tento jednoduchý postup vám umožní testovat reducery a async akce i v projektech, které nemají složité prostředí, a přitom si zachovat jistotu, že logika funguje.<br><br>Další praktický nástroj je metoda „Start – Stop – Continue". Každý člen týmu napíše jednu věc, kterou bychom měli začít dělat, jednu věc, kterou bychom měli přestat dělat, a jednu věc, kterou bychom měli dělat dál. Tyto tři kolonky pak slouží jako základ pro konkrétní akční kroky. Ke konci si vyberte jeden návrh z každé kolonky a přiřaďte k němu odpovědnou osobu a termín. Bez tohoto kroku zůstane retrospektiva jen povídáním a za dva týdny se vše vrátí do starých kolejí.<br><br>Důležité je také zvážit, jak se vaše API bude vyvíjet. REST vyžaduje při změně datového modelu často nový endpoint nebo verzi API, což přináší údržbu a zpětnou kompatibilitu. GraphQL vám umožňuje přidávat nová pole do existujícího schématu bez narušení starších klientů. Pokud ale vaše API poskytuje čistě jednoduché CRUD operace, je GraphQL zbytečně složité — jeho schéma a resolvery přidávají vrstvu abstrakce, která se nevyplatí.<br><br>Jednotkové testy reducerů a asynchronních akcí v Reduxu jsou základním kamenem robustní aplikace. Nemusíte kvůli nim spouštět celé integrační prostředí, stačí vám čistý JavaScript a pár nástrojů, které už pravděpodobně máte. Reducer je totiž čistá funkce a async akce lze testovat pomocí mockování závislostí. Tento přístup vám ušetří čas a zajistí, že logika aplikace je pokryta testy dřív, než se začnete zabývat komponentami.<br><br>Prakticky doporučuji: pro interní API, které obsluhuje vaši vlastní frontendu a vyvíjí se rychle, zvolte GraphQL. Pro veřejné API určené širokému spektru klientů, kde je důležitá stabilita a předvídatelnost, zůstaňte u REST. Pokud si nejste jisti, začněte s REST — je jednodušší a univerzálnější. GraphQL lze vždy přidat později, pokud se ukáže, že REST nestačí na rostoucí požadavky na výkon a flexibilitu.<br><br>Dalším důležitým pravidlem je netestovat implementaci, ale chování. Nezáleží na tom, jak přesně thunk vypadá uvnitř, ale jaké akce vyvolá a v jakém pořadí. Proto se vyhněte kontrole, jestli byla volána nějaká konkrétní funkce kromě dispatch. Místo toho se zaměřte na to, co uživatel nebo další části aplikace skutečně vidí. Tento přístup vám umožní později změnit interní strukturu akce bez nutnosti přepisovat testy, pokud zůstane zachováno chování.<br><br>Jakmile je jednotková vrstva pevná, přejděte na integrační testy. Ty ověřují, že vaše komponenty spolupracují správně – typicky s databází, externími službami nebo frontendem. Zde platí pravidlo: testujte jen to, co jednotkově nejde pokrýt. Například mapování ORM, SQL dotazy nebo synchronizaci mezi moduly. U integračních testů si dejte pozor na stav prostředí. Vždy používejte izolovanou testovací databázi a po každém běhu ji vracejte do původního stavu. Jinak se vám testy navzájem ovlivňují a vy strávíte hodiny hledáním chyby, která je jen artefaktem pořadí testů.<br><br>Dalším častým problémem je testování příliš mnoha věcí v jednom testu. Metoda by měla ověřovat jen jednu chování. Pokud máte metodu, která počítá a zároveň ukládá do souboru, rozdělte test na dvě části – jednu pro výpočet a druhou pro uložení. Tím snadněji najdete příčinu, když test selže. Používejte také srozumitelné názvy testů, které popisují očekávané chování, například Add_ReturnsCorrectSum_WhenGivenTwoPositiveNumbers. Takový název je samodokumentující a usnadňuje údržbu.<br><br>Začněte testováním reducerů. Vytvořte si samostatný soubor pro každý reducer a testujte ho jako obyčejnou funkci. Vstupem je aktuální stav a akce, výstupem nový stav. Ověřte, že se stav nemění, pokud akce neodpovídá žádnému případu, a že se korektně mění pro každou důležitou akci. Typická chyba: zapomenete otestovat výchozí větev, která vrací nezměněný stav. To je přitom nejdůležitější část, protože chrání před náhodnou mutací dat.<br><br>Druhým častým problémem je formátování. Pokud máte v jednom projektu Python a JavaScript, každý má jiný standard (například PEP 8 a Prettier). V nastavení IDE si pro každý jazyk definujte příslušný formátovač a zapněte „format on save". Pozor na konflikt s automatickým importem – často se stává, že IDE vloží import z jiného jazyka, což způsobí chybu. Řešením je zakázat automatické importy v souborech, které nepatří do daného jazyka.