Při testování výkonu se zaměřte na spotřebu paměti a baterie. Spusťte aplikaci, projděte několik obrazovek a vraťte se na hlavní. Sledujte, jestli paměť roste a jestli aplikace nezpomaluje. Pro měření využijte nástroje přímo v operačním systému, ale hlavně si všímejte subjektivního dojmu – dlouhé načítání nebo sekání při scrollování je pro uživatele nepřijatelné. Typická chyba je optimalizovat výkon až na konci, ale to už je aplikace plná závislostí, které se špatně mění.<br>
<br>
<br>
<br>
Typickou chybou je nastavit si pevný cíl pokrytí, například 90 %, a pak se k němu slepě upínat. To vede k tomu, že vývojáři píší testy, které jen uměle zvyšují číslo – třeba testy, které testují gettery a settery, nebo testy, které volají funkce, ale neověřují jejich výstup. Takové testy jsou k ničemu a jen zpomalují vývoj. Mnohem lepší je nastavit si cíl na úrovni modulů nebo služeb, které jsou skutečně rizikové, a u ostatních se spokojit s nižším pokrytím. Navíc si vždy ověřte, že testy opravdu selžou, když v kódu něco rozbijete. Zkuste záměrně zavést chybu a sledujte, jestli testy zachytí – pokud ne, máte falešný pocit jistoty.<br>
<br>
<br>
<br>
Základní metrikou je řádkové pokrytí, které zjistíte pomocí nástrojů, jež sledují, které řádky kódu byly při běhu testů spuštěny. Toto číslo je snadné získat, ale má zásadní nedostatek – neříká, jestli byly testy skutečně efektivní. Můžete mít sto procent pokrytí a přitom testovat jen happy path, zatímco chyby v edge casech zůstanou neodhalené. Proto byste měli vždy kombinovat řádkové pokrytí s pokrytím větví (branch coverage), které kontroluje, jestli byly projity všechny podmínky, a s pokrytím funkcí, které sleduje, zda byly volány všechny veřejné metody.<br>
<br>
<br>
<br>
<span style="font-weight: 600;">Když tým přejde na Git,</span> většina problémů nevzniká z nedostatku znalostí příkazů, ale ze špatně nastaveného workflow. Nejčastější chybou bývá, že všichni vývojáři pracují přímo na hlavní větvi a změny se prolínají bez kontroly. Přitom stačí dodržovat pár pravidel, která práci zpřehlední a zabrání konfliktům.<br>
<br>
<br>
<br>
Když se rozhodnete přispět do open source, nejčastější chybou není nedostatek znalostí, ale špatný start. Místo abyste se vrhli na první issue, které uvidíte, začněte prozkoumáním projektu. Přečtěte si soubor s pokyny pro přispěvatele, pokud existuje. Většina větších projektů má jasně daná pravidla, jak vypadá dobrý pull request, jak psát commit messages a jaké testy se spouští. Bez této znalosti riskujete, že vaše práce bude zamítnuta, i když je technicky správná.<br>
<br>
<br>
<br>
Kdy přestat zvyšovat pokrytí a zaměřit se na jiné věci Pokrytí testy je užitečné do určité hranice, obvykle kolem 70–80 % řádků. Nad touto hranicí začíná být nárůst pokrytí drahý a přináší jen malou hodnotu. Důvod je jednoduchý – testy, které pokrývají zbývající řádky, jsou často složité na napsání, jsou křehké a mění se s každým refaktoringem. Místo abyste se snažili pokrýt posledních dvacet procent, zaměřte se na testy kritických částí aplikace, jako je platební logika, autentizace nebo zpracování dat. Tyto části by měly mít pokrytí co nejvyšší, zatímco u méně důležitých funkcí si můžete dovolit nižší čísla.<br>
<br>
<br>
<br>
Základem je rozdělit si práci na menší celky a každý z nich řešit ve vlastní větvi. Před začátkem práce si vždy vytvořte větev z aktuálního stavu hlavní větve. Používejte výstižné názvy, které popisují úkol, třeba 'oprava-prihlasovani' nebo 'pridani-filtru'. Hlavní větev udržujte stabilní – nikdy do ní necommitěte přímo, pokud nepíšete jen drobnou opravu dokumentace. Tím zajistíte, že hlavní větev je vždy ve stavu, který lze nasadit.<br>
<br>
<br>
<br>
Když už máte vybraný úkol, vytvořte si vlastní větev z aktuálního hlavního větvení. Než začnete psát kód, zkuste si projekt spustit lokálně. To je častý kámen úrazu — mnoho začátečníků skočí rovnou na editaci souborů, aniž by viděli, jak projekt funguje. Nastavení prostředí může trvat hodiny, ale je to nezbytná investice. Pokud narazíte na problém, hledejte řešení v dokumentaci projektu, nepište hned do chatu. Když už se zeptáte, buďte konkrétní: uveďte operační systém, verzi nástrojů a přesný výstup z příkazů.<br>
<br>
<br>
<br>
<img src="https://www.freepixels.com/class=" style="max-width:440px;float:left;padding:10px 10px 10px 0px;border:0px;">Pokrytí testy je oblíbená metrika, ale jen málokdo ví, jak ji správně měřit. Většina týmů se zaměří na procento řádků, které testy projdou, a zapomene, že číslo samo o sobě neříká nic o kvalitě testů. Když se pokrytí blíží sto procentům, může to vypadat skvěle, ale ve skutečnosti to často znamená, že testy jsou povrchní a netestují klíčové scénáře. Jak tedy měřit pokrytí správně a kdy přestat honit čísla?
