Code Coverage inom mobilutveckling: vad det är, mätvärden och hur man mäter

Vad är Code Coverage

Code Coverage (kodtäckning) är ett kvantitativt mätvärde som avgör vilken del av applikationens källkod som har exekverats under testerna. Det uttrycks i procent och beräknas som förhållandet mellan antalet exekverade rader/grenar och totalantalet. Hög täckning garanterar inte frånvaro av buggar, men minskar risken för förbisedda fel.

Varför mäta täckning

Kodtäckning hjälper teamet: att hitta otestade områden i koden, fatta beslut om prioriteringar för att skriva tester, följa dynamiken i testkvalitet i CI/CD. Inom mobilutveckling är täckning särskilt viktig för affärslogik, datamodeller och databaser — lager där sannolikheten för fel är störst.

Myter om Code Coverage

En vanlig myt: ”100% täckning = idealisk kvalitet”. I praktiken uppnås 100% täckning extremt sällan och ofta till priset av ytliga tester. Effektiv täckning är inte en tävling om procent, utan strategisk täckning av kritiska vägar och gränsvillkor. Täckning säger ingenting om kvaliteten på själva testerna: ett test kan godkännas men inte kontrollera resultatets korrekthet.

Mätvärden för kodtäckning

Det finns flera mätvärden för Code Coverage, som var och en mäter olika aspekter av testning. Line coverage (radtäckning) är det enklaste mätvärdet som visar procentandelen exekverade kodrader. Branch coverage (grantäckning) mäter vilka if-else och switch-förgreningar som har testats.

Radttäckning (Line Coverage)

Line coverage räknar varje källkodsrad som exekverad eller inte. Om en rad innehåller en villkorsoperator eller loop, anses raden vara exekverad om kontrollen nådde den, även om inte alla grenar har bearbetats. Detta är det minst stränga mätvärdet, men det mest lättförståeliga för visuell bedömning.

Grantäckning (Branch Coverage)

Branch coverage utvärderar om alla möjliga grenar i koden har testats. För varje if-else beaktas båda grenarna: true och false. För switch — varje case. Branch coverage anses vara ett strängare mätvärde än line coverage och upptäcker oftare otestade scenarier.

Sökvägstäckning (Path Coverage)

Path coverage — det strängaste mätvärdet som kräver kontroll av alla möjliga kombinationer av förgreningar i en funktion. I praktiken används path coverage sällan på grund av den exponentiella ökningen av antalet kombinationer: en funktion med 10 förgreningar har 1024 möjliga sökvägar.

Verktyg för att mäta täckning

Inom mobilutveckling används olika verktyg för att mäta Code Coverage beroende på plattform. För Android är standarden JaCoCo (Java Code Coverage), som integreras med Gradle och stöder både enhetstester och instrumentella tester. För iOS används XCCov, inbyggt i Xcode.

JaCoCo för Android

JaCoCo genererar rapporter i HTML-, XML- och CSV-format. HTML-rapporten markerar rader visuellt: grön — exekverade, röd — hoppade över, gul — delvis exekverade. XML-rapporten är kompatibel med SonarQube och andra kodanalyssystem. JaCoCo stöder filtrering av klasser: genererad kod, databinding, BuildConfig kan exkluderas.

// build.gradle — JaCoCo-konfiguration
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// Skapa JaCoCo-rapport
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

XCCov för iOS

XCCov — Xcodes inbyggda verktyg för att mäta kodtäckning. Det aktiveras via Gather coverage data i testschemat. XCCov stöder täckning för Swift och Objective-C, genererar rapporter i .xccovreport och integreras med CI via xcodebuild -enableCodeCoverage YES. Data visas i konsolen och kan exporteras till JSON.

SonarQube och Codecov

För centraliserad övervakning av täckning används plattformar: SonarQube (kodkvalitetsanalys + täckning), Codecov och Coveralls. Dessa tjänster samlar data från JaCoCo och XCCov, visar trender, Quality Gate och integration med GitHub/GitLab via PR-kommentarer.

Hur man förbättrar kodtäckning

Att öka Code Coverage kräver ett systematiskt tillvägagångssätt: inte ”öka procenten”, utan täcka risker. Första steget är att analysera JaCoCo- eller XCCov-rapporten — identifiera röda (otäckta) klasser. Prioritet: affärslogik → databaser → ViewModel → UI-komponenter.

TDD-strategi

Test-Driven Development (TDD) säkerställer automatiskt hög täckning, eftersom tester skrivs före implementeringen. Process: röd (skriv ett test som misslyckas) → grön (skriv minimal kod) → refaktorisering. TDD disciplinerar utvecklaren och tvingar denne att täcka gränsfall och exceptionella situationer som ofta förblir utan tester.

Parametriserade tester

Ett parametriserat test ersätter dussintals vanliga tester. JUnit och XCTest stöder parametrisering: @ParameterizedTest i JUnit 5, XCTestCase med testPerformanceExample i XCTest. Parametrisering gör det möjligt att kontrollera flera indata utan att duplicera kod, vilket avsevärt utökar täckningen av grenar och villkor.

// Parametriserat test i Kotlin med 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)
}

Misstag vid arbete med Code Coverage

Det vanligaste misstaget — jakt på procent utan analys av testkvalitet. Teamet börjar skriva tester för testandets skull: kontrollera getters och setters, duplicera täckning på olika nivåer, testa triviala metoder. Detta ger en hög procentandel men ökar inte den verkliga kvaliteten.

Falsk känsla av säkerhet

Hög Code Coverage kan skapa en falsk uppfattning om att applikationen är väl testad. Ett test kan exekvera en kodrad men inte kontrollera resultatets korrekthet. Till exempel: testet anropar en metod för rabattberäkning men kontrollerar inte beloppet — raden exekveras, täckningen ökar, men buggen hittas inte.

Ignorera gränsfall

Typiskt misstag — att bara testa ”den lyckliga vägen” (happy path) och ignorera gränsfall: tomma listor, null-värden, maximala tal, ogiltiga format. De flesta buggar uppstår just vid gränser och undantag. Branch coverage hjälper till att upptäcka missade grenar, men garanterar inte kontroll av gränsvärden.

Mutation Testing — kontroll av testkvalitet

Mutation Testing är en metod för att utvärdera testkvalitet där mutationer (konstgjorda fel) introduceras i källkoden och man kontrollerar om testerna misslyckas. Pitest — populärt verktyg för mutation testing för Java och Kotlin. Om tester inte misslyckas på en mutation — betyder det att de inte kontrollerar det villkoret.

Pitests funktionsprincip

Pitest skapar mutanter — modifierade kopior av källkoden, där till exempel > har ersatts med >=, true med false, eller ett metodanrop har tagits bort. Sedan körs tester för varje mutant. Om testerna godkänns — överlevde mutanten, vilket innebär att testerna inte täcker detta scenario. Om testerna misslyckas — har mutanten dödats, testet är korrekt.

// build.gradle — Pitest-konfiguration
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
}

Typer av mutationer

Pitest stöder många typer av mutationer: ändring av villkorsoperatorer (== → !=, < → <=), borttagning av metodanrop, ersättning av returvärden (true → false), ändring av aritmetiska operationer (+ → -), mutation av inkrement (i++ → i--). Ju fler mutationstyper som dödas av tester, desto pålitligare är testpaketet.

Mutation Score-mål

Målet för mutation score — 80% och högre. Detta innebär att 80% av de konstgjorda felen har upptäckts av tester. Kodtäckning (Code Coverage) på 90% garanterar inte att tester hittar fel — mutation testing ger en mer objektiv bedömning. Pitest kan integreras i CI som Quality Gate och blockera bygget när mutation score sjunker under tröskeln.

Integration av Code Coverage i CI/CD

För automatisk kontroll av Code Coverage i CI/CD används Quality Gates — tröskelvärden, vid vars överträdelse bygget markeras som instabilt eller avvisas. SonarQube gör det möjligt att konfigurera Quality Gate baserat på en kombination av mätvärden: täckning (≥80%), antal buggar, sårbarheter och duplicerad kod.

Konfiguration av Quality Gate i GitHub Actions

I GitHub Actions integreras Code Coverage via actionssteg: körning av tester med täckning → uppladdning av rapport till Codecov → kontroll av tröskel. Codecov kommenterar automatiskt PR:en med täckningsdiff och visar vilka rader som ändrats och hur det påverkat den totala procentandelen. Om täckningen har minskat — blockeras PR:en tills ytterligare tester har skrivits.

# GitHub Actions — ladda upp täckning till 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

Rapportering och visualisering

HTML-rapporter från JaCoCo och XCCov innehåller visuell markering av täckning: grönt — exekverade rader, rött — icke-exekverade. SonarQube visar även täckning på fil-, klass-, metod- och radnivå, samt historik över täckningsförändringar per sprint. Detta hjälper till att fatta beslut om refaktorisering och tillägg av tester.