Když testy rostou bez řádu: Jak je zkrotit pyramidou

Častou chybou je také snažit se odhadnout čas bez dostatečných informací. Než cokoli slíbíte, zeptejte se na detaily zadání. Čím víc toho víte o rozsahu práce, tím přesnější odhad můžete dát. Pokud informace chybí, řekněte to na rovinu: „Teprve po analýze zadání vám dám konkrétnější termín." Zákazník ocení, že nejednáte naslepo. Když se ale zadání během práce změní, nebojte se odhad aktualizovat. Mlčet až do termínu a pak omlouvat zpoždění je to nejhorší, co můžete udělat. Včasná komunikace o novém odhadu je známkou profesionality.

Pokud máte více feature větví, které spolu souvisí, zvažte, zda je neřešit na jedné větvi, ale postupně. Často se stává, že dvě větve mění stejný soubor a po mergu druhé z nich vzniknou zbytečné konflikty. Místo toho si práci naplánujte tak, aby se větve vzájemně nepřekrývaly, nebo je slučte do jedné „epické" větve, kterou pak mergnete najednou. Tím se vyhnete situaci, kdy máte pět větví čekajících na merge a každá obsahuje změny, které závisí na jiné.

Změna podpisu a další pokročilé operace Pokud potřebujete upravit parametry funkce, využijte Change Signature (Ctrl+F6). IDE najde všechna volání a automaticky je upraví podle nového podpisu. Tento nástroj je užitečný zejména při práci s knihovnami, kde se změny často opakují. Před jeho použitím si ale ověřte, zda jsou všechna volání v projektu skutečně nalezena – pokud používáte dynamickou reflexi nebo generování kódu, může IDE některá volání přehlédnout. V takovém případě je vhodné přidat dočasně chybný parametr, aby kompilátor na chybějící volání upozornil.

Kde nejčastěji pyramida padá a jak to napravit Nejčastější chybou je obrácená pyramida – když máte stovky end-to-end testů a jen pár jednotkových. Tým pak tráví více času opravováním testů než vývojem funkcí. Příčinou bývá snaha testovat všechno přes uživatelské rozhraní, protože „to je nejvěrnější obraz toho, co uživatel vidí". Jenže takový přístup ignoruje, že každý end-to-end test je pomalý a náchylný k selhání kvůli načasování, animacím nebo změnám v rozvržení. Řešení není testy mazat, ale přesunout většinu scénářů na nižší úrovně. Logiku, která se skrývá za formulářem, otestujte na úrovni jednotek nebo integrace. End-to-end testy si nechte jen na kritické cesty – přihlášení, platbu nebo registraci.

U jednotkových testů si dejte pozor na testování implementace místo chování. Testujte, co funkce dělá, ne to, jak to dělá. Když test začnete plnit kontrolami vnitřních stavů, každá refaktorizace kódu test rozbije, i když chování zůstává stejné. U integračních testů zase hrozí, že budete testovat samotnou databázi, což je zbytečné. Zaměřte se na to, aby test prokázal, že vaše vrstvy spolu správně komunikují, ne že databáze funguje – to už ověřil její výrobce.

Co se stane, když podceníte správu závislostí Jakmile začnete přidávat knihovny pro práci se sítí nebo databází, přichází první velká překážka: konflikty verzí. Typická chyba je přidat knihovnu podle vzoru z internetu bez kontroly, zda odpovídá vaší verzi Androidu a minSdk. Výsledkem je pak chyba, že aplikace padá hned po spuštění, nebo dokonce neprojde kompilací. Aby se to nestalo, vždy čtěte dokumentaci knihovny a sledujte, jakou minimální verzi systému vyžaduje. Pokud váš projekt má nižší minSdk, buď ji zvyšte, nebo knihovnu nechte na později. Také se vyhněte zbytečným knihovnám – každá zvyšuje velikost aplikace a prodlužuje čas kompilace.

Jak často a jakým způsobem aktualizovat větev Pravidelně si do své feature větve tahněte změny z hlavní větve, ideálně každý den. Používejte rebase místo merge, pokud jste si jisti, že vaše větev nikdo další nesdílí. Rebase udělá historii lineárnější a usnadní pozdější code review. Pokud ale na větvi pracuje více lidí, merge je bezpečnější volbou. Nezapomeňte, že rebase přepisuje historii, takže u sdílených větví způsobí konflikty ostatním.

Testovací pyramida není jen hezký obrázek z přednášek o kvalitě kódu. Je to praktický nástroj, který vám pomůže udržet testovací sadu rychlou, stabilní a hlavně užitečnou. Pokud ji ignorujete, dříve nebo později narazíte na situaci, kdy spuštění všech testů trvá hodiny, každá změna v kódu rozbije desítky testů a nikdo už neví, co vlastně testy ověřují. Tento článek se zaměřuje na to, jak pyramidu skutečně použít, na co si dát pozor a jakým chybám se vyhnout.

Druhým krokem je nastavit si projekt správně hned od začátku. Vytvořte si prázdný projekt s prázdnou aktivitou, ne s šablonami, které generují zbytečný kód. Už od prvního dne si zvykněte na verzovací systém, ideálně git, a každou funkční změnu commitujte. Když to neuděláte, po třech dnech práce narazíte na chybu, kterou nebudete schopni vrátit zpět, a to vás bude stát hodiny hledání. Důležité je také používat emulátor – fyzické zařízení je sice rychlejší, ale emulátor vám umožní testovat různé velikosti obrazovek a systémové verze.