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ě.

Co dělat, když se odhad začne posouvat Termín se posune skoro vždy, protože se objeví něco, co nikdo nečekal. Rozdíl mezi profesionálem a amatérem není v tom, že by se nic nepokazilo, ale v tom, kdy o tom klient ví. Ozvěte se v momentě, kdy zjistíte odchylku, ne až v den, kdy mělo být hotovo. Přineste tři věci: co se změnilo, co to znamená pro termín a co navrhujete dál. Konkrétně, ne omluvy typu „je toho hodně".

Konzistence a nástroje místo dohadován

Kde začátečníci nejčastěji chybují První chyba je ignorování autentizace. Mnoho API vyžaduje klíč, který se posílá v hlavičce požadavku. Bez něj dostanete chybu 401 nebo 403. Klíč nikdy neukládejte do veřejného kódu, jinak ho někdo zneužije. Druhá chyba je přehlížení limitů. API často omezuje počet požadavků za minutu. Pokud limit překročíte, dostanete chybu 429 a budete muset čekat. Naučte se číst dokumentaci – je to jediné místo, kde se dozvíte přesné názvy parametrů a formát odpovědi.

Naučte se odmítnout termín, o kterém víte, že je nesmyslný. Věta „tohle v tomto termínu nestihneme" je profesionální odpověď, ne slabost. Doplňte ji tím, co stihnout lze: co je nejmenší hodnota, kterou dokážete dodat včas. Klient většinou ocení jasné „ne" s alternativou víc než zdvořilé „uvidíme". Poslední pravidlo: co jste slíbili, zapište. Ústní dohoda se v hlavách obou stran mění a zápis je jediná obrana proti tomu, aby se z odhadu stal spor.

Kdy se z pokrytí stává past Pokrytí přestává být užitečné ve chvíli, kdy se stane cílem místo nástroje. Typickým projevem je test, který zavolá funkci, ale nekontroluje výsledek. Nebo testy, které jen procházejí kód, aby zvýšily procento. Dalším varovným signálem je snaha dostat se na sto procent za každou cenu. Poslední procenta obvykle znamenají testy pro triviální gettery, obsluhu výjimek, které nikdy nenastanou, nebo mrtvý kód. Náklady rostou, přínos klesá.

Druhá hranice je ekonomická. Pokrytí má smysl dotahovat tam, kde chyba způsobí reálné škody: platby, autentizace, výpočty, integrace. U prezentační vrstvy, jednorázových skriptů nebo prototypů je návratnost nízká. Vyplatí se stanovit si cílové pokrytí podle kritičnosti modulu, ne plošně. Někde stačí třicet procent, jinde má smysl tlačit na devadesát. Rozhodujte se podle rizika, ne podle toho, co vypadá dobře v reportu.

Typická chyba je komunikovat odhad jako jedno číslo. Mnohem poctivější je říct rozsah: „S velkou pravděpodobností to bude v tomto týdnu, nejpozději do konce příštího." Rozsah dává klientovi prostor plánovat a vám prostor dýchat. Nikdy ale nerozšiřujte rozsah jen proto, abyste měli klid. Když se vejdete do spodní hranice, řekněte to. Důvěra se buduje hlavně na tom, že se trefujete do toho, co jste sami slíbili.

Většina vývojářů při refaktoringu sahá po myši a ručně přepisuje názvy, přesouvá bloky a hledá výskyty očima. Přesně tím ale ztrácí čas, který mohly ušetřit vestavěné nástroje v editoru nebo IDE. Nejde o žádné pluginy ani doplňky — mluvíme o funkcích, které má každé rozumné vývojové prostředí už v sobě. Problém je, že je lidé buď neznají, nebo je používají špatně a nadělají víc škody než užitku.

Klient se ptá, kdy bude hotovo. Je to přirozené a je to fér. Problém vzniká ve chvíli, kdy odpovíte číslem, které jste si právě vymysleli na místě. Závazný termín je totiž slib a slib se nevymýšlí, ten se počítá. První pravidlo tedy zní: než cokoli řeknete, rozdělte si práci na části a u každé si napište, co konkrétně znamená „hotovo" a kdo na ni musí navázat.

Měření pokrytí testy vypadá jako jednoduché číslo, které stačí sledovat. Právě v tom je ale největší past. Pokrytí říká jen to, které řádky kódu se při běhu testů vykonaly. Neříká, jestli testy něco ověřují, jestli mají smysluplné assertions, ani jestli pokrývají rizikové scénáře. Tým, který honí procenta, často skončí s vysokým číslem a nízkou důvěrou v kód.

První krok je měřit pokrytí tam, kde má vypovídací hodnotu. Zaměřte se na nový a měněný kód, ne na celý repozitář. Zaveďte pravidlo, že každá změna chování přichází s testem, který ji ověřuje. Pokrytí pak sledujte jako trend u kritických modulů, ne jako globální metriku pro celý projekt. U staršího kódu je lepší postupně přidávat testy k částem, které skutečně upravujete, než plošně nutit tým dopisovat testy všude.