Testovací pyramida, o které většina týmů omylem zapomíná

Dále se zaměřte na dobu běhu. Pokud máte testy, které trvají déle než pět minut, rozdělte je do vrstev: rychlé (jednotkové), střední (integrace s jednou komponentou) a pomalé (end-to-end). Rychlé spouštějte při každém commitu, střední při každém pull requestu a pomalé až před nasazením do produkce. Tím zajistíte, že vývojáři dostanou zpětnou vazbu rychle, ale složité scénáře nezmizí. Nezapomeňte také na flaky testy – pokud test občas selže bez zjevné příčiny, buď ho opravte, nebo zahoďte. Jinak začnete ignorovat červené výsledky a celý systém ztratí důvěryhodnost.

Jak najít rovnováhu, když už je pozdě Nejdřív si udělejte mapu současného stavu. Projděte si testy v repozitáři a rozdělte je podle toho, co skutečně ověřují. Jednotkové testy, které potřebují databázi, síť nebo souborový systém, jsou ve skutečnosti integrační a je třeba je tak i chápat. Toto překlasifikování vám ukáže, kde je poměr vychýlený. Často zjistíte, že máte stovky jednotkových testů, které jen opakují logiku implementace, a přitom chybí pár klíčových integračních testů pokrývajících hlavní toky aplikace.

Začněte tím, že si v každém IDE nebo editoru definujete pro každý jazyk samostatný profil nebo workspace. Většina moderních nástrojů to umožňuje přes takzvané workspace settings. Určete pro každý jazyk vlastní formátovač, linter a pravidla pro zalamování řádků. Například Python nebude tolerovat stejnou šířku řádku jako JavaScript. Pokud toto nastavíte globálně, bude se vám kód v každém jazyce formátovat jinak, než tým očekává. Typická chyba je mít pro všechny soubory jednotný formát, což vede k nekonečným diskuzím v code review.

Další chybou bývá přenášení citlivých dat přímo v payloadu JWT. Token je podepsaný, ale ne šifrovaný, takže jeho obsah si může přečíst každý, kdo ho získá. Do tokenu proto patří pouze identifikátory uživatele, role a případně další neveřejné, ale ne citlivé údaje. Hesla, čísla karet nebo osobní údaje do tokenu nikdy nepatří. Pokud potřebujete tokenem přenášet citlivé informace, použijte JWE, ale v drtivé většině případů je lepší token jen podepsat a data uchovávat na serveru.

Práce na projektu, který kombinuje více jazyků, je častější, než se zdá. Typicky jde o backend v Javě, frontend v TypeScriptu, pár skriptů v Pythonu a šablonu v HTML s CSS. Mnoho vývojářů ale stále používá jedno prostředí nastavené na jeden jazyk, což vede k věčné přepínací smyčce mezi konfiguracemi. Přitom stačí věnovat půl hodiny nastavení IDE, aby se všechny jazyky jako jeden celek. Klíčem je nesnažit se mít všechno zapnuté najednou, ale nastavit si kontexty, které se mění podle toho, co právě píšete.

Další praktický krok je nastavit si pro každý jazyk vlastní terminál nebo příkazovou řádku. Mnoho projektů má skripty pro build spouštěné v různých prostředích. Pokud máte jeden terminál, který se přepíná podle aktuálního souboru, ušetříte si spoustu klikání. V praxi to znamená, že když stojíte v souboru Python, terminál se automaticky spustí s virtuálním prostředím. Když přejdete na JavaScript, terminál se přepne do Node.js prostředí. To vám umožní spouštět testy a linting bez ručního zadávání příkazů. Ale pozor, tohle vyžaduje, aby byl každý jazyk izolovaný ve svém vlastním adresáři nebo alespoň měl jasně oddělené konfigurační soubory.

Na závěr si zkuste celý projekt otevřít bez jediného ručního zásahu. Pokud se IDE zeptá, který jazyk má pro daný soubor použít, znamená to, že ještě nemáte správně nastavené automatické rozpoznávání. V ideálním případě by mělo být vše připravené tak, že otevřete projekt a můžete okamžitě psát kód v jakémkoli jazyce. Toto nastavení vám ušetří hodiny času, které byste jinak strávili přepínáním konfigurací a řešením chyb, které vznikly jen kvůli špatnému kontextu.

Jak vypadá zdravá hierarchie a kde ji nejčastěji rozbijete Funkční základ pyramidy tvoří jednotkové testy. Měly by pokrývat izolovanou logiku bez závislostí na databázi, síti nebo časovačích. Pokud test potřebuje připojení k databázi nebo mockování pěti vrstev, není to jednotkový test, ale integrační test byt v paneláku převleku. Integrační testy patří do prostřední vrstvy – ověřují spolupráci modulů, ale stále by měly být rychlé a stabilní. Na vrcholu stojí malý počet E2E testů, které kontrolují kritické uživatelské cesty. Častá chyba? Píšete E2E testy pro každou maličkost, protože „to je přece nejvěrnější simulace". To je cesta do pekla.

Jak zvládnout přepínání mezi jazyky bez ztráty kontextu Vyzkoušejte funkci automatické detekce typu souboru podle přípony a podle obsahu. IDE si sám přepne zvýrazňování syntaxe a načte příslušné pluginy. Důležité je ale nastavit i klávesové zkratky pro přepínání mezi jednotlivými jazykovými režimy. Například když upravujete soubor .tsx, měl by se vám aktivovat linter pro TypeScript a React. Když otevřete soubor .py, měla by se vypnout kontrola typů z TypeScriptu a zapnout Pythoní linter. Většina nástrojů to umí, ale je potřeba si to vědomě nakonfigurovat. Bez toho se vám stane, že vám IDE hlásí chyby v souborech, které zrovna nespouštíte, a vy ztrácíte čas.