Když pokrytí testy klame: měřte správně, ať nemáte falešný pocit jistoty
Typické chyby, které kazí dojem z aplikace Mezi nejčastější prohřešky patří ignorování stavu načítání. Když uživatel klikne na tlačítko a nic se neděje, má pocit, že se aplikace zasekla. Vždy poskytněte zpětnou vazbu – ať už jde o spinner, změnu barvy tlačítka nebo text „Ukládám…". Stejně důležité je ošetřit chybové stavy: místo obecného „Došlo k chybě" napište konkrétně, co se nepovedlo a jak to uživatel může opravit. Například „Zkontrolujte připojení k internetu" nebo „Zadané heslo je příliš krátké". Uživatel pak nemusí hádat a může problém rychle vyřešit.<br>
<br>
<br>
<br>
Další častý problém je testování na nesprávném zařízení. Ne každý má nejnovější model, takže otestujte aplikaci na starším zařízení s menším rozlišením a pomalejším procesorem. Zkuste také změnit velikost písma v systémovém nastavení nebo zapnout režim úspory baterie. Tyto faktory dokážou rozbít layout, který na vývojářském zařízení vypadá perfektně. Pozor i na orientaci obrazovky – přepnutí z portrétu na šířku by nemělo resetovat stav aplikace nebo ztratit data z formuláře.<br>
<br>
<br>
<br>
Nakonec si osvojte zvyk pravidelně testovat vlastní návrhy. Není nutné mít laboratoř – stačí, když si sednete k hotové obrazovce a projdete si hlavní úkoly, jako byste byli uživatel. Zeptejte se sami sebe: Kde váhám? Co je nejasné? Jak dlouho mi trvalo najít klíčovou funkci? Takovýto self-test odhalí mnoho nedostatků dřív, než aplikaci vypustíte do světa. A když můžete, nechte si návrh projít někým, kdo vaši aplikaci nezná – jeho pohled je přesně ten, který potřebujete.<br>
<br>
<br>
<br>
Časté chyby, které vás zpomalí, a jak se jim vyhnout Největší pastí bývá překlad s proměnnými. V češtině se skloňuje a pořadí slov se liší od angličtiny, takže řetězec „Čekejte count sekund" v angličtině „Wait count seconds" nefunguje univerzálně. Řešením je používat tzv. pluralizaci, kterou podporují moderní systémy – definujete zvlášť tvary pro jeden, dva a pět kusů. Stejně tak pozor na spojování řetězců pomocí plus znaménka – to je cesta do pekla. Vždy používejte placeholder, který umožní měnit pořadí slov podle jazyka.<br>
<br>
<br>
<br>
Základní pravidlo zní: jedna logická změna = jeden commit. Pokud opravujete dva různé bugy nebo přidáváte dvě nesouvisející funkce, rozdělte je. Jinak později nemůžete snadno vrátit nebo izolovat konkrétní krok. Prakticky to znamená, že před odesláním commitu si projděte diff a zeptejte se, zda všechny změny spolu souvisí. Pokud ne, použijte git add -p pro výběr jednotlivých hunků. Historie pak bude připomínat čistý příběh, ne guláš z náhodných úprav.<br>
<br>
<br>
<br>
Začni s něčím malým. Vyber metodu, která nemá žádné vedlejší účinky, ideálně čistou funkci. Čistá funkce vrací výsledek pouze na základě svých argumentů a nemění žádný stav. Typicky to je matematická operace, formátování textu nebo transformace dat. Dej si pozor na metody, které čtou čas, generují náhodná čísla nebo přistupují k souborům. Tyto metody vyžadují mockování a injektování závislostí, což je pro první test zbytečně složité. Tvůj cíl je jednoduchý: ověřit, že funkce vrací očekávanou hodnotu pro konkrétní vstup.<br>
<br>
<br>
<br>
Druhým krokem je práce s vizuální hierarchií. Uživatel by měl na první pohled vidět, co je nejdůležitější. Vytvořte jasný kontrast mezi primárním a sekundárním prvkem – hlavní akční tlačítko zvýrazněte, vedlejší akce ztlumte nebo umístěte stranou. Nezapomeňte na dostatečné mezery mezi prvky; přeplácané obrazovky působí chaoticky a zvyšují chybovost. Místo mnoha barev použijte jednu akcentovou barvu pro interakce a neutrální pro pozadí. Testujte také čitelnost textu – minimální velikost písma pro běžný obsah by měla být alespoň 16 pixelů, a to nejen na mobilu.<br>
<br>
<br>
<br>
Při psaní testu se vyhni podmínkám uvnitř testu. Test by měl být přímý a lineární. Pokud potřebuješ otestovat více variant, napiš více testů, ne jeden s podmínkou. Také se vyhni kontrole, že test prošel, pomocí výpisu do konzole. Testovací framework ti sám řekne, jestli test prošel nebo selhal. Používej jeho nativní assertion metody, ne vlastní podmínky s výstupem. A pozor na testy, které závisí na pořadí. Každý test by měl být samostatný a spustitelný nezávisle na ostatních. To znamená, že si test sám připraví svá data a nepočítá s tím, že je nachystal jiný test.<br>
<br>
<br>
<br>
Typická chyba, kterou vidím u týmů, je honba za stonásobným pokrytím za každou cenu. Programátoři pak píší testy, které jen volají funkce s triviálními vstupy, nebo používají nástroje, které uměle navyšují čísla — třeba provádějí kód přes reflexi nebo vypínají kontroly. Výsledkem je, že metrika vypadá skvěle, ale testy nechytí jedinou skutečnou chybu. Stejně problematické je i pokrytí, které se měří jen v jednom momentě — po změně kódu je často neaktuální. Doporučuji měřit pokrytí průběžně v CI a nastavit si minimální hranici, ale jen jako pojistku proti výraznému propadu, ne jako cíl.