Co se stane, když jednotkové testy přestanou stačit

Commit message Pište v rozkazovacím způsobu a k věci: „Opravit řazení položek v košíku" místo „oprava". První řádek do padesáti znaků, případné podrobnosti do těla. Častá chyba je míchat do jednoho commitu nesouvisející změny — formátování, opravu chyby a novou funkci. Takový commit se nedá vrátit zpět, aniž byste vrátili i to, co má zůstat. Rozdělte práci na menší celky ještě předtím, než začnete commitovat.

Kdy je interní tým past a kdy výhoda Vlastní tým má smysl tam, kde je potřeba hluboká znalost prostředí, dlouhodobá návaznost a rychlá reakce na změny. Naopak u jednorázových, jasně ohraničených úkolů často přináší víc režie než užitku. Pastí je i to, že se interní lidé bojí říct si o pomoc, protože nechtějí vypadat neschopně. Manažer proto musí aktivně zjišťovat, kde se práce zasekává, ne jen kontrolovat termíny.

První měsíce nejsou o výkonu, ale o zvyku. Nastav si rutinu: ráno si přečti, co se změnilo v repozitáři, odpoledne si zapiš, čemu nerozumíš. Každý den pošli alespoň jednu otázku do týmového kanálu. Neptej se „jak to funguje", ale „vidím tady volání téhle funkce, chápu správně, že vrací seznam?" Konkrétní otázka ukazuje, že jsi kód četl. Obecná otázka ukazuje, že jsi ho neotevřel.

Typické chyby se opakují. Testovací data se zapisují natvrdo do kódu, takže testy padají při změně prostředí. Testy závisí na sobě navzájem a jejich pořadí rozhoduje o výsledku. Čekání se řeší pevnými prodlevami místo čekání na konkrétní stav, což vede k náhodným selháním. Automatizované testy se spouštějí jen na emulátoru a nikdy na skutečném zařízení. A často chybí testy pro obnovení stavu po přerušení – třeba když uživatel přijme hovor uprostřed nahrávání.

Verzování začíná jediným příkazem, ale většina problémů vzniká ještě před ním. Než poprvé spustíš git init, nastav si jméno a e-mail, které se zapisují do každého commitu: git config --global user.name "Jan Novák" a git config --global user.email "jan@example.com". Bez toho Git odmítne commit vytvořit nebo použije nesmyslné údaje, které se pak těžko zpětně mění. Stejně důležité je rozhodnout, co do repozitáře nepatří — soubory s hesly, lokální konfigurace, build výstupy. Vytvoř soubor .gitignore dřív, než uděláš první commit, protože dodatečné vyřazování už sledovaných souborů je otrava.

Rozdělení práce mezi vlastní tým zní lákavě: žádné faktury, žádné čekání na cizí lidi, všechno pod kontrolou. Jenže právě tady vzniká většina zpoždění. Nejde o to, že by interní lidé byli horší než externisté. Jde o to, že projekt s vlastním týmem nemá žádné přirozené hranice. Práce se rozplyne do běžného provozu a najednou není jasné, kdo co dělá a do kdy.

Zásadní je definovat hranici mezi jednotkovým a integračním testem. Jednotkový test ověřuje jednu logickou jednotku bez vedlejších efektů – typicky funkci nebo metodu s izolovanými závislostmi. Integrační test naopak ověřuje spolupráci dvou a více reálných komponent: například úložiště s databází, řadič s validátorem nebo službu s HTTP klientem. Pokud tuto hranici nemáte pojmenovanou, začnou vznikat „testy nanečisto", které jsou pomalé, křehké a nikdo neví, co vlastně ověřují.

První věc, kterou je potřeba udělat ještě před startem, je oddělit projekt od rutiny. Znamená to pojmenovat, kdo je za co odpovědný, a hlavně kolik času na to skutečně má. Pokud člověk dělá na projektu vedle své každodenní agendy, musí být tento čas explicitně vyčleněný. Bez toho se projekt posouvá vždy až na druhé místo. Typická chyba je spoléhat na to, že to lidé nějak zvládnou. Nezvládnou.

Kde jednotkové testy ztrácejí smysl Nejčastější chybou je snaha pokrýt jednotkovými testy i to, co je ve skutečnosti orchestrace. Testujete-li deset mocků v jednom testu, netestujete logiku, ale konfiguraci. Takový test se rozbije při každé změně pořadí volání a jeho údržba stojí více než přínos. Řešením je nahradit tyto „mockovací monstra" integračním testem, který použije skutečné komponenty nebo jejich lehké náhrady (in-memory databáze, fake HTTP server). Získáte test, který vydrží refaktoring a odhalí skutečné chyby v propojení.

Projekty s vlastním týmem nepadají na nedostatku schopností, ale na nedostatku hranic, rozhodnutí a průběžné kontroly. Kdo si tyto tři věci nastaví předem, mívá projekt hotový v rozumném čase i bez externí pomoci.

Růst codebase je neúprosný. Zatímco počet tříd a modulů roste lineárně, počet vzájemných vazeb roste kvadraticky. Jednotkové testy, které dříve pokrývaly vše, najednou narážejí na to, že izolovaná logika neodhalí chyby ve spolupráci komponent. Prvním krokem k vyvážení je přiznat, že jednotkové testy nejsou univerzální řešení. Měly by zůstat rychlé a deterministické, ale jejich množství je třeba cíleně omezit ve prospěch testů integračních.