Začněte tím, že si vezmete posledních deset chyb, které se dostaly do produkce. U každé zapište, proč ji testy nezachytily. Výsledkem bude seznam mezer: chybějící okrajové případy, špatně nastavená data, neošetřené chyby vstupů. Tento seznam je cennější než jakékoli procento. Z něj odvoďte nové testy, které skutečně selžou, když se chyba vrátí. Ověřte to tak, že test nejprve spustíte proti vadnému kódu a teprve pak proti opravenému.

Izolované testy reducerů a thunků jsou rychlé, deterministické a odhalí chyby v logice dřív, než se dostanou do integrace. Nezastoupí test celého toku, ale výrazně zkrátí dobu hledání příčiny. Když reducer i async akce projdou samostatně, je mnohem snazší najít problém ve chvíli, kdy se spojí dohromady.

Vzdálený repozitář není automatická záloha. git push odešle commity, git pull stáhne cizí změny. Pokud push odmítne s hláškou o nesouhlasných historiích, neznamená to, že máš použít --force. Nejdřív si přečti, co je na serveru nového, a sluč. Vynucený push přepíše práci ostatních a v týmovém prostředí je to nejrychlejší cesta k rozbitému projektu. Pro začátek stačí pamatovat: commituj často, ale po malých ucelených změnách, a před každým push si projdi git log --oneline, ať víš, co odesíláš.

U dávkového vkládání a hromadných aktualizací se často objevuje jiná chyba: aplikace spojí více hodnot do jednoho dotazu a zapomene, že počet parametrů musí odpovídat počtu zástupných symbolů. Pokud se počet neshoduje, vývojář sáhne po ručním skládání a tím vrátí injektáž zpět do hry. Bezpečnější je zpracovat dávku po menších částech nebo použít jeden připravený dotaz v cyklu, i za cenu mírně vyšší režie.

Když míra pokrytí roste, ale počet odhalených chyb neroste, přestává být užitečná. Typický stav je, že testy pokrývají hlavně jednoduché cesty a zapomínají na chybové stavy. Další varovný signál: testy jsou křehké, padají při každé drobné změně a lidé je přestanou spravovat. Jakmile údržba testů zabere více času než psaní nového kódu, pokrytí škodí.

Druhý častý problém je práce s transakcemi a zámky. MySQL má výchozí autocommit a特定 chování u nevýkonných dotazů, PostgreSQL je přísnější. Dlouhé transakce blokují úklid starých verzí řádků a mohou nafouknout databázi. Při migraci proto zkontrolujte, zda aplikace neotevírá transakce zbytečně dlouho. Pozor také na ON DUPLICATE KEY UPDATE — v PostgreSQL použijete INSERT … ON CONFLICT. Nahrazení není mechanické, musíte určit konfliktní sloupec.

Migrace z MySQL do PostgreSQL není jen převod typů sloupců. Rozdíly v chování serveru se projeví až v provozu: jinak se chovají transakce, jinak řazení textu, jinak výchozí hodnoty. Pokud začnete přepisem schématu bez přípravy, narazíte na chyby, které se v MySQL nikdy neobjevily. Nejprve si udělejte inventuru: které tabulky jsou kritické, kde se používají uložené procedury, triggery a kde aplikace spoléhá na nestandardní chování MySQL.

Před spuštěním na produkci si připravte testovací prostředí se stejnou verzí PostgreSQL a stejnou kolací. Prožeňte aplikaci všemi scénáři, včetně prázdných výsledků a chybových stavů. Po přenosu dat spusťte ANALYZE, aby plánovač dostal statistiky. Zkontrolujte sekvence a identity — po hromadném importu je často potřeba posunout jejich aktuální hodnotu, jinak další vložení selže na duplicitní klíč. Migrace není jednorázový skript, ale několik ověřených kroků, které se vyplatí opakovat, dokud nejsou výsledky shodné.

Async akce testujte přes thunk a fake dispatch Async akce v Reduxu bývá thunk – funkce, která dostane dispatch a getState. Testujete ji tak, že jí předáte vlastní dispatch, který si zaznamenává volání, a getState, který vrací připravený stav. Po zavolání await na návratovou hodnotu zkontrolujete, které akce byly odeslány a v jakém pořadí. Nepotřebujete žádné HTTP připojení, pokud síťovou vrstvu nahradíte atrapou.

Míra pokrytí testy se často bere jako ukazatel kvality. Jenže vysoké procento samo o sobě nic neznamená. Pokrytí říká pouze to, které řádky kódu testy prošly, ne jestli ověřují správné chování. Mnohem užitečnější je sledovat, jaké chyby vám testy reálně zachytí. Pokud po nasazení stejně nacházíte závady, které testy měly odhalit, je pokrytí jen číslo do reportu.

Praktický postup začíná exportem dat. Z MySQL vytáhněte schéma i data zvlášť, ideálně v režimu, který neobsahuje komentáře specifické pro MySQL a příkazy pro vypnutí kontrol cizích klíčů. Data exportujte jako čisté INSERTy nebo CSV. Při převodu schématu převeďte typy: TINYINT(1) často končí jako BOOLEAN, DATETIME nahraďte TIMESTAMP nebo TIMESTAMPTZ podle toho, zda potřebujete časová pásma. AUTO_INCREMENT nahraďte GENERATED … AS IDENTITY nebo SERIAL. ENUM v PostgreSQL nahraďte vlastním typem nebo tabulkou s číselníkem, jinak narazíte na problémy při změnách hodnot.