Začni tím, že si pokrytí změříš jen na novém nebo upravovaném kódu. Celorepozitářové číslo je zavádějící, protože starý kód bez testů ho sráží dolů a nutí tě psát testy tam, kde se nic nemění. Praktický postup: nastav nástroj tak, aby reportoval pokrytí změněných řádků v rámci pull requestu, a stanov jen minimální hranici pro nový kód. Tím se vyhneš hromadění prázdných testů, které sice zvyšují procento, ale netestují žádné chování.

Základní cyklus je pořád stejný: upravíte soubor, přidáte ho do přípravy přes git add a změnu uložíte přes git commit. Začátečníci často přeskočí git add a diví se, že commit je prázdný. Druhá častá chyba je git add . bez rozmyšlení, které přidá i dočasné soubory, logy nebo konfigurace s hesly. Řešením je soubor .gitignore vytvořený hned na začátku, kde uvedete vzory jako *.log, build/ nebo .env. Co je v .gitignore zapsané, Git přestane sledovat, ale až od okamžiku přidání pravidla — už sledované soubory je nutné odstranit z indexu přes git rm --cached.

Začněte tím, že si napíšete, co má uživatel na dané obrazovce stihnout. Jedna obrazovka, jeden hlavní úkol. Pokud jich je víc, rozdělte je. Tlačítka, odkazy a formulářová pole jsou nástroje, ne dekorace. Když má stránka pět stejně výrazných akcí, žádná z nich není hlavní. Vizuální hierarchie není o barvách, ale o pořadí, v jakém oko putuje po ploše. Nadpis, primární akce, obsah — v tomto sledu. Vše ostatní má být vizuálně tišší.

Formuláře jsou místo, kde se ztrácí nejvíc konverzí. Každé pole navíc snižuje ochotu dokončit akci. Ptejte se jen na to, co skutečně potřebujete, a zbytek zjistěte později. Popisky patří nad pole, ne dovnitř jako placeholder, protože ten po napsání zmizí a uživatel zapomene, co vyplňuje. Validujte při odchodu z pole, ne při každém stisku klávesy. Chybová zpráva má být u konkrétního pole a konkrétní, ne souhrnná dole pod formulářem.

TypeScript není jiný jazyk, je to JavaScript s typy. Kód se před spuštěním přeloží do běžného JavaScriptu, takže prohlížeč ani Node.js nic nového nepotřebují. Rozdíl je v tom, že už při psaní víte, jaká data funkce očekává a co vrací. U malého skriptu na jednu stránku to může být zbytečná práce. Ve chvíli, kdy projekt roste, přibývají lidé nebo se mění datové struktury, se ale bez typů opravují chyby, které mohly být odhaleny dřív, než kód vůbec poběží.

První návyk se týká izolace. Každý test musí být nezávislý na pořadí, v jakém ho runner spustí, a nesmí měnit stav, který ovlivní ostatní testy. V praxi to znamená, že sdílená data nevytváříte v jednorázovém setupu na úrovni třídy, pokud je testy pouze čtou a nikdy nemění. Jakmile test zapisuje do statické kolekce, do souboru nebo do databáze, potřebuje vlastní instanci. NUnit k tomu nabízí atributy [SetUp] a [TearDown], které se volají před a po každém testu, nikoli před a po celé třídě. Záměna těchto úrovní je nejčastější příčina testů, které procházejí samostatně, ale padají ve skupině.

TypeScript není nový jazyk, který bys musel učit od nuly. Je to JavaScript s typovou vrstvou, kterou projde kompilátor a teprve pak vznikne spustitelný kód. V praxi to znamená, že do stávajícího projektu přidáš soubor tsconfig.json, přejmenuješ část souborů z .js na .ts a postupně doplňuješ typy. Nemusíš přepisovat všechno najednou. Kompilátor umí být nastavený tak, že chybějící typy nehlásí jako chybu, takže migrace může být plynulá.

Poslední věc, kterou je dobré řešit včas, je build. TypeScript se musí zkompilovat do JavaScriptu, a to buď před nasazením, nebo průběžně při vývoji. Pokud se kompilace a spouštění rozjedou, vznikají zdánlivě nepochopitelné chyby. Drž výstupní adresář oddělený od zdrojových souborů a nástroje pro vývoj nastav tak, aby pracovaly se zdroji, ne s výstupem. Tím se vyhneš zmatkům, které s typovým systémem vůbec nesouvisí.

Než začnete ladit detaily, otestujte tok s pěti lidmi. Sledujte, kde se zaseknou, ne co říkají, že se jim líbí. Opravte jedno místo, otestujte znovu. Design není fáze projektu, ale průběžná kontrola toho, jestli rozhraní dělá to, co jste zamýšleli. Nejčastější chyba není nedostatek talentu, ale přeskočení tohoto kroku.

Typový systém v TypeScriptu je strukturální, ne nominální. Dvě různé třídy se stejným tvarem jsou vzájemně zaměnitelné. To je výhoda při práci s daty z API, ale zároveň past: stačí přejmenovat pole a kompilátor může přestat rozumět. Proto se vyplatí držet typy pohromadě s daty, která popisují. Když se mění odpověď serveru, mění se i rozhraní, a to je vidět na jednom místě.