Code Coverage v mobilním vývoji: co to je, metriky a jak měřit

Co je Code Coverage

Code Coverage (pokrytí kódu) je kvantitativní metrika, která určuje, která část zdrojového kódu aplikace byla provedena během testů. Vyjadřuje se v procentech a vypočítá se jako poměr počtu provedených řádků/větví k celkovému počtu. Vysoké pokrytí nezaručuje absenci chyb, ale snižuje riziko přehlédnutých chyb.

Proč měřit pokrytí

Pokrytí kódu pomáhá týmu: najít neotestované části kódu, rozhodovat o prioritách psaní testů, sledovat dynamiku kvality testování v CI/CD. V mobilním vývoji je pokrytí obzvlášť důležité pro business logiku, datové modely a repozitáře — vrstvy s nejvyšší pravděpodobností chyb.

Mýty o Code Coverage

Rozšířený mýtus: „100% pokrytí = ideální kvalita“. V praxi je 100% pokrytí dosaženo velmi zřídka a často za cenu povrchních testů. Efektivní pokrytí — není závod o procento, ale strategické pokrytí kritických cest a okrajových podmínek. Pokrytí neříká nic o kvalitě samotných testů: test může projít, ale nekontrolovat správnost výsledku.

Metriky pokrytí kódu

Existuje několik metrik Code Coverage, z nichž každá měří různé aspekty testování. Line coverage (pokrytí řádků) — nejjednodušší metrika ukazující procento provedených řádků kódu. Branch coverage (pokrytí větví) měří, která větvení if-else a switch byla testována.

Pokrytí řádků (Line Coverage)

Line coverage počítá každý řádek zdrojového kódu jako provedený nebo ne. Pokud je na řádku podmíněný operátor nebo smyčka, řádek je považován za provedený, pokud k němu řízení dospělo, i když nebyly zpracovány všechny větve. Toto je nejméně přísná metrika, ale nejsrozumitelnější pro vizuální hodnocení.

Pokrytí větví (Branch Coverage)

Branch coverage vyhodnocuje, zda byly všechny možné větve v kódu testovány. Pro každý if-else se berou v úvahu obě větve: true a false. Pro switch — každý case. Branch coverage je považována za přísnější metriku než line coverage a častěji odhaluje netestované scénáře.

Pokrytí cest (Path Coverage)

Path coverage — nejpřísnější metrika vyžadující kontrolu všech možných kombinací větvení ve funkci. V praxi se path coverage používá zřídka kvůli exponenciálnímu růstu počtu kombinací: funkce s 10 větvemi má 1024 možných cest.

Nástroje pro měření pokrytí

V mobilním vývoji se používají různé nástroje pro měření Code Coverage v závislosti na platformě. Pro Android je standardem JaCoCo (Java Code Coverage), který se integruje s Gradle a podporuje jak unit testy, tak instrumentační testy. Pro iOS se používá XCCov, vestavěný v Xcode.

JaCoCo pro Android

JaCoCo generuje zprávy ve formátech HTML, XML a CSV. HTML zpráva vizuálně zvýrazňuje řádky: zelená — provedené, červená — přeskočené, žlutá — částečně provedené. XML zpráva je kompatibilní se SonarQube a dalšími systémy analýzy kódu. JaCoCo podporuje filtrování tříd: lze vyloučit generated kód, databinding, BuildConfig.

// build.gradle — nastavení JaCoCo
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// Vytvoření zprávy JaCoCo
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

XCCov pro iOS

XCCov — vestavěný nástroj Xcode pro měření pokrytí kódu. Aktivuje se pomocí Gather coverage data ve schématu testování. XCCov podporuje pokrytí pro Swift a Objective-C, generuje zprávy v .xccovreport a integruje se s CI pomocí xcodebuild -enableCodeCoverage YES. Data se zobrazují v konzoli a lze je exportovat do JSON.

SonarQube a Codecov

Pro centralizované monitorování pokrytí se používají platformy: SonarQube (analýza kvality kódu + pokrytí), Codecov a Coveralls. Tyto služby agregují data z JaCoCo a XCCov, zobrazují trendy, Quality Gate a integraci s GitHub/GitLab prostřednictvím komentářů PR.

Jak zlepšit pokrytí kódu

Zvyšování Code Coverage vyžaduje systematický přístup: ne „dovádět procenta“, ale uzavírat rizika. Prvním krokem je analýza zprávy JaCoCo nebo XCCov — identifikace červených (nekrytých) tříd. Priorita: business logika → repozitáře → ViewModel → UI komponenty.

Strategie TDD

Test-Driven Development (TDD) automaticky zajišťuje vysoké pokrytí, protože testy se píší před implementací. Proces: červená (napiš test, který selže) → zelená (napiš minimální kód) → refaktorování. TDD disciplinuje vývojáře a nutí ho pokrývat okrajové případy a výjimečné situace, které často zůstávají bez testů.

Parametrizované testy

Jeden parametrizovaný test nahrazuje desítky běžných. JUnit a XCTest podporují parametrizaci: @ParameterizedTest v JUnit 5, XCTestCase s testPerformanceExample v XCTest. Parametrizace umožňuje kontrolovat mnoho vstupních dat bez duplikování kódu, což výrazně rozšiřuje pokrytí větví a podmínek.

// Parametrizovaný test v Kotlin s JUnit 5
@ParameterizedTest
@ValueSource(strings = ["user@test.com", "admin@test.com", "test@example.com"])
fun `validate email returns true for valid addresses`(email: String) {
    val result = EmailValidator.isValid(email)
    Assertions.assertTrue(result)
}

Chyby při práci s Code Coverage

Nejčastější chyba — honba za procentem bez analýzy kvality testů. Tým začne psát testy pro testy: kontroluje gettry a settry, duplikuje pokrytí na různých úrovních, testuje triviální metody. To dává vysoké procento, ale nezvyšuje skutečnou kvalitu.

Falešný pocit bezpečí

Vysoké Code Coverage může vytvořit falešný dojem, že aplikace je dobře otestována. Test může provést řádek kódu, ale nezkontrolovat správnost výsledku. Například: test volá metodu výpočtu slevy, ale nekontroluje částku — řádek je proveden, pokrytí roste, ale chyba není nalezena.

Ignorování okrajových případů

Typická chyba — testovat pouze „šťastnou cestu“ (happy path) a ignorovat okrajové případy: prázdné seznamy, null hodnoty, maximální čísla, nesprávné formáty. Většina chyb vzniká právě na hranicích a výjimkách. Branch coverage pomáhá odhalit vynechané větve, ale nezaručuje kontrolu okrajových hodnot.

Mutation Testing — kontrola kvality testů

Mutation Testing je metoda hodnocení kvality testů, při které se do zdrojového kódu vnášejí mutace (umělé chyby) a kontroluje se, zda testy selžou. Pitest — populární nástroj mutation testing pro Java a Kotlin. Pokud testy na mutaci neselhaly — znamená to, že neověřují danou podmínku.

Princip činnosti Pitest

Pitest vytváří mutanty — upravené kopie zdrojového kódu, ve kterých je například > nahrazeno >=, true za false, nebo je odstraněno volání metody. Poté se pro každého mutanta spustí testy. Pokud testy projdou — mutant přežil, což znamená, že testy tento scénář nepokrývají. Pokud testy selžou — mutant byl zabit, test je správný.

// build.gradle — nastavení Pitest
plugins {
    id 'info.solidsoft.pitest' version '1.15.0'
}

pitest {
    targetClasses = ['com.example.app.*']
    targetTests = ['com.example.app.*Test']
    threads = 4
    outputFormats = ['HTML', 'XML']
    mutationThreshold = 80
    coverageThreshold = 85
}

Typy mutací

Pitest podporuje mnoho typů mutací: změna podmíněných operátorů (== → !=, < → <=), odstranění volání metod, nahrazení návratových hodnot (true → false), změna aritmetických operací (+ → -), mutace inkrementace (i++ → i--). Čím více typů mutací je testy zabito, tím spolehlivější je testovací sada.

Cíl Mutation Score

Cílové mutation score — 80% a více. To znamená, že 80% umělých chyb bylo testy detekováno. Pokrytí kódu (Code Coverage) 90% nezaručuje, že testy nacházejí chyby — mutation testing poskytuje objektivnější hodnocení. Pitest může být integrován do CI jako Quality Gate, blokující sestavení při poklesu mutation score pod práh.

Integrace Code Coverage do CI/CD

Pro automatickou kontrolu Code Coverage v CI/CD se používají Quality Gates — prahové hodnoty, při jejichž porušení je sestavení označeno jako nestabilní nebo zamítnuto. SonarQube umožňuje konfigurovat Quality Gate na základě kombinace metrik: pokrytí (≥80%), počet chyb, zranitelností a duplikovaného kódu.

Nastavení Quality Gate v GitHub Actions

V GitHub Actions se Code Coverage integruje prostřednictvím akčních kroků: spuštění testů s pokrytím → nahrání zprávy do Codecov → kontrola prahu. Codecov automaticky komentuje PR s diffem pokrytí a ukazuje, které řádky se změnily a jak to ovlivnilo celkové procento. Pokud pokrytí kleslo — PR je blokováno do napsání dalších testů.

# GitHub Actions — nahrání pokrytí do Codecov
- name: Run Tests with Coverage
  run: ./gradlew testDebugUnitTest jacocoTestReport

- name: Upload to Codecov
  uses: codecov/codecov-action@v4
  with:
    files: ./app/build/reports/jacoco/jacocoTestReport.xml
    flags: unittests
    fail_ci_if_error: true

- name: Check Coverage Threshold
  run: |
    coverage=$(grep -oP 'branchCoverage="\K[0-9.]+' report.xml)
    if (( $(echo "$coverage < 80" | bc -l) )); then
      echo "Coverage $coverage% is below 80% threshold"
      exit 1
    fi

Hlášení a vizualizace

HTML zprávy JaCoCo a XCCov obsahují vizuální zvýraznění pokrytí: zelená — provedené řádky, červená — neprovedené. SonarQube navíc ukazuje pokrytí na úrovni souboru, třídy, metody a řádku, stejně jako historii změn pokrytí podle sprintů. To pomáhá při rozhodování o refaktorování a přidávání testů.