Code Coverage a mobilfejlesztésben: mi ez, mérőszámok és hogyan mérjük

Mi az a Code Coverage

Code Coverage (kódlefedettség) egy mennyiségi mérőszám, amely meghatározza, hogy az alkalmazás forráskódjának mely része hajtódott végre a tesztek során. Százalékban fejezik ki, és a végrehajtott sorok/ágak számának és az összes számnak az arányaként számítják ki. A magas lefedettség nem garantálja a hibák hiányát, de csökkenti a kihagyott hibák kockázatát.

Miért mérjük a lefedettséget

A kódlefedettség segíti a csapatot: megtalálni a kód nem tesztelt részeit, döntéseket hozni a tesztek írásának prioritásairól, nyomon követni a tesztelés minőségének dinamikáját a CI/CD-ben. A mobilfejlesztésben a lefedettség különösen fontos az üzleti logika, adatmodellek és repository-k — a legnagyobb hibavalószínűségű rétegek — esetében.

Tévhitek a Code Coverage-ről

Egy elterjedt tévhit: „100% lefedettség = ideális minőség“. A gyakorlatban a 100%-os lefedettség rendkívül ritkán érhető el, és gyakran felületes tesztek árán. Hatékony lefedettség — nem verseny a százalékért, hanem a kritikus útvonalak és határfeltételek stratégiai lefedése. A lefedettség nem mond semmit a tesztek minőségéről: egy teszt átmehet, de nem ellenőrzi az eredmény helyességét.

Kódlefedettség mérőszámai

A Code Coverage-nek több mérőszáma létezik, amelyek mindegyike a tesztelés különböző aspektusait méri. Line coverage (sorlefedettség) — a legegyszerűbb mérőszám, amely a végrehajtott kódsorok százalékát mutatja. Branch coverage (ágfedettség) azt méri, hogy mely if-else és switch elágazások lettek tesztelve.

Sorlefedettség (Line Coverage)

A Line coverage minden forráskód-sort végrehajtottként vagy nem végrehajtottként számol. Ha egy sorban feltételes operátor vagy ciklus található, a sor végrehajtottnak minősül, ha a vezérlés elérte, még ha nem is minden ág lett feldolgozva. Ez a legkevésbé szigorú mérőszám, de a vizuális értékelés szempontjából a legérthetőbb.

Ágfedettség (Branch Coverage)

A Branch coverage azt értékeli, hogy a kódban lévő összes lehetséges elágazás tesztelve lett-e. Minden if-else esetében mindkét ágat figyelembe veszi: true és false. Switch esetén — minden case-t. A Branch coverage szigorúbb mérőszámnak számít, mint a line coverage, és gyakrabban tárja fel a nem tesztelt forgatókönyveket.

Útvonalfedettség (Path Coverage)

A Path coverage — a legszigorúbb mérőszám, amely egy függvény összes lehetséges elágazás-kombinációjának ellenőrzését igényli. A gyakorlatban a path coverage ritkán használatos a kombinációk exponenciális növekedése miatt: egy 10 elágazással rendelkező függvénynek 1024 lehetséges útvonala van.

Lefedettségmérő eszközök

A mobilfejlesztésben különböző eszközöket használnak a Code Coverage mérésére a platformtól függően. Android esetében a szabvány a JaCoCo (Java Code Coverage), amely integrálódik a Gradle-lel, és támogatja mind az egységteszteket, mind az instrumentációs teszteket. iOS esetében az Xcode-ba épített XCCov-ot használják.

JaCoCo Androidhoz

A JaCoCo HTML, XML és CSV formátumú jelentéseket generál. A HTML-jelentés vizuálisan kiemeli a sorokat: zöld — végrehajtott, piros — kihagyott, sárga — részben végrehajtott. Az XML-jelentés kompatibilis a SonarQube-val és más kódanalizáló rendszerekkel. A JaCoCo támogatja az osztályok szűrését: a generated kód, databinding, BuildConfig kizárható.

// build.gradle — JaCoCo beállítása
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// JaCoCo jelentés létrehozása
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

XCCov iOS-hez

Az XCCov — az Xcode beépített eszköze a kódlefedettség mérésére. A tesztelési sémában a Gather coverage data segítségével aktiválható. Az XCCov támogatja a Swift és Objective-C lefedettségét, .xccovreport formátumú jelentéseket generál, és CI-vel az xcodebuild -enableCodeCoverage YES-en keresztül integrálható. Az adatok a konzolban jelennek meg, és JSON-ba exportálhatók.

SonarQube és Codecov

A központosított lefedettségfigyeléshez platformokat használnak: SonarQube (kódminőség-elemzés + lefedettség), Codecov és Coveralls. Ezek a szolgáltatások összegyűjtik az adatokat a JaCoCo-ból és XCCov-ból, mutatják a trendeket, a Quality Gate-t és a GitHub/GitLab integrációt PR-megjegyzéseken keresztül.

Hogyan javítsuk a kódlefedettséget

A Code Coverage növelése szisztematikus megközelítést igényel: ne „verd fel a százalékot”, hanem fedezd le a kockázatokat. Az első lépés a JaCoCo vagy XCCov jelentés elemzése — a piros (nem lefedett) osztályok azonosítása. Prioritás: üzleti logika → repository-k → ViewModel → UI-komponensek.

TDD-stratégia

A Test-Driven Development (TDD) automatikusan magas lefedettséget biztosít, mivel a tesztek a megvalósítás előtt készülnek. Folyamat: piros (írj egy hibás tesztet) → zöld (írd meg a minimális kódot) → refaktorálás. TDD fegyelemre szoktatja a fejlesztőt, arra kényszerítve, hogy lefedje a határeseteket és kivételes helyzeteket, amelyek gyakran teszt nélkül maradnak.

Paraméterezett tesztek

Egy paraméterezett teszt tucatnyi szokásos tesztet helyettesít. A JUnit és az XCTest támogatja a paraméterezést: @ParameterizedTest a JUnit 5-ben, XCTestCase a testPerformanceExample-val az XCTest-ben. A paraméterezés lehetővé teszi több bemeneti adat ellenőrzését a kód duplikálása nélkül, ami jelentősen kiterjeszti az ágak és feltételek lefedettségét.

// Paraméterezett teszt Kotlinban JUnit 5-tel
@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)
}

Hibák a Code Coverage használatában

A leggyakoribb hiba — százalékvadászat a tesztek minőségének elemzése nélkül. A csapat elkezd teszteket írni a tesztelés kedvéért: ellenőrzi a gettereket és settereket, duplikálja a lefedettséget különböző szinteken, triviális metódusokat tesztel. Ez magas százalékot ad, de nem növeli a valódi minőséget.

Hamis biztonságérzet

A magas Code Coverage hamis benyomást kelthet, hogy az alkalmazás jól tesztelt. Egy teszt végrehajthat egy kódsort, de nem ellenőrzi az eredmény helyességét. Például: a teszt meghívja a kedvezmény kiszámításának metódusát, de nem ellenőrzi az összeget — a sor végrehajtódott, a lefedettség nő, de a hibát nem találták meg.

Határesetek figyelmen kívül hagyása

Tipikus hiba — csak a „boldog utat” (happy path) tesztelni, és figyelmen kívül hagyni a határeseteket: üres listák, null értékek, maximális számok, érvénytelen formátumok. A hibák többsége pont a határokon és kivételeknél fordul elő. A Branch coverage segít a kihagyott ágak feltárásában, de nem garantálja a határértékek ellenőrzését.

Mutation Testing — a tesztek minőségének ellenőrzése

A Mutation Testing a tesztek minőségének értékelési módszere, amely során mutációkat (mesterséges hibákat) vezetnek be a forráskódba, és ellenőrzik, hogy a tesztek megbuknak-e. Pitest — népszerű mutation testing eszköz Java-hoz és Kotlin-hoz. Ha a tesztek nem buknak meg a mutáción — az azt jelenti, hogy nem ellenőrzik azt a feltételt.

A Pitest működési elve

A Pitest mutánsokat hoz létre — a forráskód módosított másolatait, ahol például a > helyett >=, a true helyett false szerepel, vagy egy metódushívás törlődik. Ezután minden mutánsra lefuttatják a teszteket. Ha a tesztek átmennek — a mutáns túlélte, ami azt jelenti, hogy a tesztek nem fedik le ezt a forgatókönyvet. Ha a tesztek megbuknak — a mutáns elpusztult, a teszt helyes.

// build.gradle — Pitest beállítása
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
}

Mutációk típusai

A Pitest számos mutációtípust támogat: feltételes operátorok megváltoztatása (== → !=, < → <=), metódushívások eltávolítása, visszatérési értékek cseréje (true → false), aritmetikai műveletek megváltoztatása (+ → -), inkrementáció mutációja (i++ → i--). Minél több mutációtípust ölnek meg a tesztek, annál megbízhatóbb a tesztkészlet.

Mutation Score cél

A cél mutation score — 80% és afelett. Ez azt jelenti, hogy a mesterséges hibák 80%-át a tesztek felfedezték. A 90%-os kódlefedettség (Code Coverage) nem garantálja, hogy a tesztek megtalálják a hibákat — a mutation testing objektívebb értékelést ad. Pitest integrálható a CI-be Quality Gate-ként, blokkolva a build-et, ha a mutation score a küszöb alá esik.

Code Coverage integrációja a CI/CD-be

A Code Coverage automatikus ellenőrzéséhez a CI/CD-ben Quality Gates — küszöbértékek használatosak, amelyek megsértése esetén a build instabilnak minősül vagy elutasításra kerül. SonarQube lehetővé teszi a Quality Gate konfigurálását a mérőszámok kombinációja alapján: lefedettség (≥80%), hibák száma, sebezhetőségek és duplikált kód.

Quality Gate beállítása GitHub Actions-ben

A GitHub Actions-ben a Code Coverage akció lépéseken keresztül integrálódik: tesztek futtatása lefedettséggel → jelentés feltöltése a Codecov-ba → küszöb ellenőrzése. Codecov automatikusan kommentálja a PR-t a lefedettség diff-jével, megmutatva, mely sorok változtak és hogyan befolyásolták a teljes százalékot. Ha a lefedettség csökkent — a PR blokkolva lesz a további tesztek megírásáig.

# GitHub Actions — lefedettség feltöltése Codecov-ba
- 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

Jelentéskészítés és vizualizáció

A JaCoCo és XCCov HTML-jelentései vizuális lefedettségkiemelést tartalmaznak: zöld — végrehajtott sorok, piros — nem végrehajtott. SonarQube emellett megmutatja a lefedettséget fájl-, osztály-, metódus- és sor szinten, valamint a lefedettség változásának történetét sprintek szerint. Ez segít döntéseket hozni a refaktorálásról és a tesztek hozzáadásáról.