Edytujesz Když se testy množí, rozhoduje jejich uspořádání

Testovací pyramida není dogma, ale poměr, který udržuje zpětnou vazbu rychlou a levnou. Základ tvoří unit testy: měly by pokrývat izolovanou logiku, hraniční hodnoty a chybové stavy. Držte je v řádu milisekund, bez sítě, bez souborového systému a bez databáze. Když unit test potřebuje kontejner nebo běžící server, není to unit test. Čím více jich je, tím častěji můžete spouštět celou sadu při každé změně.<br><br>Kde parametrizace končí a začíná ruční prá<br><br>Na závěr: verzování není o složitých příkazech, ale o návyku. Commitovat po malých krocích, kontrolovat stav přes git status a nikdy nespouštět destruktivní příkazy bez rozmyšlení. Když si osvojíte těchto pár zásad, přestane být Git hrozbou a stane se nástrojem, který vás podrží, když se něco pokazí.<br><br>Nad nimi stojí integrační testy. Ověřují spolupráci dvou až tří komponent: například že se data správně uloží a načtou, že se zpráva odešle do fronty, že se zavolá rozhraní. Tyto testy už mohou používat reálnou databázi nebo její lehkou náhradu. Nepoužívejte je ale jako náhradu za unit testy. Typická chyba je, že tým přesune veškerou logiku do integračních testů, protože se snáze píší. Výsledkem je pomalá sada, která padá z nesouvisejících důvodů a nikdo jí nevěří.<br><br>Git ukládá historii projektu jako sérii snímků. Každý snímek vznikne tak, že označíte změny příkazem git add a uložíte je příkazem git commit -m "popis". Tento commit je pak dohledatelný podle jedinečného hashe. Pokud ho neuděláte, změny zůstanou jen v pracovním adresáři a při přepnutí větve nebo neopatrném příkazu git checkout -- . zmizí bez varování. Proto platí: když dokončíte logický celek, commitněte. Ne za hodinu, ne večer, ale hned.<br><br>Při růstu codebase se vyplatí měřit dobu běhu a míru selhání. Pokud jednotkové testy trvají déle než několik sekund, něco je špatně. Pokud integrační testy padají na náhodných chybách, je problém v izolaci nebo v prostředí. Sledujte, které testy nejčastěji padají a proč, a opravujte příčinu, ne test. Nakonec platí, že hranice mezi jednotkovými a integračními testy není dogmatická, ale musí být jasná a dodržovaná. Když ji tým zná a respektuje, růst kódu přestane být noční můrou.<br><br>Větev main není posvátná, ale její přepsání bolí Většina začátečníků pracuje přímo na větvi main. To není zakázané, ale při experimentu je snadné vytvořit zmatek. Vytvořte si novou větev: git switch -c pokus. Pracujte na ní, commitněte a teprve potom ji slučte zpět příkazem git switch main a git merge pokus. Když experiment selže, stačí se vrátit na main a větev smazat: git branch -d pokus. Tím se vyhnete přepisování funkční historie a zbytečnému panikaření.<br><br>Poslední oblastí jsou moduly. import a export nahrazují staré globální proměnné a okamžitě zpřehlední strukturu projektu. Při importu používejte relativní cesty a pojmenované exporty. Pokud exportujete výchozí hodnotu, importujte ji bez složených závorek. Častá chyba je cyklická závislost, kdy modul A importuje B a B importuje A. Tomu se vyhněte rozdělením kódu nebo přesunem společné logiky do třetího modulu. Moderní JavaScript není o tom naučit se všechny novinky nazpaměť, ale vědět, kdy kterou použít a kde naopak zvolit starší, ale bezpečnější postup.<br><br>Vyhněte se dvěma častým omylům. Prvním je snaha mít „test na všechno" a měřit kvalitu procentem pokrytí. Pokrytí říká, co je spuštěno, ne co je ověřeno. Druhým je ignorování rychlosti. Test, který běží deset minut, vývojáři přestanou pouštět. Rozdělte sadu na rychlou, která běží při každém commitu, a pomalou, která se spouští před vydáním. Každý test musí mít jasný důvod, proč existuje. Když ho neumíte pojmenovat, pravděpodobně jen zdržuje.<br><br>Šipky, rozbalování a další každodenní pomocníci Arrow funkce jsou krátké a přebírají this z okolního kontextu. To je výhoda v metodách pole, ale problém v objektech, kde potřebujete vlastní this. Pokud si nejste jistí, raději použijte klasickou funkci. Rozbalování objektů a polí výrazně zkracuje kód. Například const jmeno, vek = uzivatel; vytáhne vlastnosti do samostatných proměnných. Pozor na kolizi názvů — pokud už proměnná existuje, musíte ji přejmenovat pomocí dvojtečky. U polí funguje podobně [prvni, druhy] = pole;, ale nezapomeňte, že se jedná o přiřazení, ne o kopii celého pole.<br><br>Pro vzdálenou spolupráci slouží git push a git pull. Po prvním propojení s remote úložištěm stačí git push -u origin main. Před každým pushnutím si stáhněte změny ostatních: git pull --rebase. Vyhnete se zbytečným merge commitům a konfliktům, které vznikají zbytečně. Konflikt neřešte panickým mazáním souborů. Otevřete soubor, najděte značky >>>>>>, ručně vyberte správnou verzi, soubor uložte, přidejte přes git add a dokončete rebase nebo merge commitem.