Code Coverage in der mobilen Entwicklung: Was es ist, Metriken und wie man es misst

Was ist Code Coverage

Code Coverage (Codeabdeckung) ist eine quantitative Metrik, die bestimmt, welcher Teil des Quellcodes der Anwendung während der Tests ausgeführt wurde. Sie wird in Prozent ausgedrückt und als Verhältnis der ausgeführten Zeilen/Zweige zur Gesamtzahl berechnet. Eine hohe Abdeckung garantiert keine fehlerfreie Software, reduziert jedoch das Risiko übersehener Fehler.

Warum Abdeckung messen

Die Codeabdeckung hilft dem Team: ungetestete Codebereiche zu finden, Entscheidungen über Prioritäten beim Schreiben von Tests zu treffen und die Dynamik der Testqualität in CI/CD zu verfolgen. In der mobilen Entwicklung ist die Abdeckung besonders wichtig für Geschäftslogik, Datenmodelle und Repositories — Schichten, in denen die Fehlerwahrscheinlichkeit am höchsten ist.

Mythen über Code Coverage

Ein verbreiteter Mythos: „100 % Abdeckung = perfekte Qualität“. In der Praxis ist eine 100%ige Abdeckung äußerst selten und wird oft auf Kosten oberflächlicher Tests erreicht. Effektive Abdeckung ist kein Wettlauf um Prozente, sondern eine strategische Abdeckung kritischer Pfade und Grenzfälle. Die Abdeckung sagt nichts über die Qualität der Tests selbst aus: Ein Test kann bestehen, aber die Korrektheit des Ergebnisses nicht überprüfen.

Metriken der Codeabdeckung

Es gibt mehrere Code-Coverage-Metriken, die jeweils verschiedene Aspekte des Testens messen. Line Coverage (Zeilenabdeckung) ist die einfachste Metrik und zeigt den Prozentsatz der ausgeführten Codezeilen. Branch Coverage (Zweigabdeckung) misst, welche if-else- und switch-Verzweigungen getestet wurden.

Zeilenabdeckung (Line Coverage)

Line Coverage zählt jede Quellcodezeile als ausgeführt oder nicht ausgeführt. Enthält eine Zeile einen bedingten Operator oder eine Schleife, gilt die Zeile als ausgeführt, wenn die Steuerung sie erreicht hat, auch wenn nicht alle Zweige verarbeitet wurden. Dies ist die am wenigsten strenge Metrik, aber für die visuelle Bewertung am verständlichsten.

Zweigabdeckung (Branch Coverage)

Branch Coverage bewertet, ob alle möglichen Zweige im Code getestet wurden. Für jedes if-else werden beide Zweige berücksichtigt: true und false. Für switch wird jeder case berücksichtigt. Branch Coverage gilt als strengere Metrik als Line Coverage und deckt häufiger ungetestete Szenarien auf.

Pfadabdeckung (Path Coverage)

Path Coverage ist die strengste Metrik und erfordert die Überprüfung aller möglichen Kombinationen von Zweigen in einer Funktion. In der Praxis wird Path Coverage aufgrund des exponentiellen Wachstums der Anzahl von Kombinationen selten verwendet: Eine Funktion mit 10 Zweigen hat 1024 mögliche Pfade.

Tools zur Messung der Abdeckung

In der mobilen Entwicklung werden je nach Plattform verschiedene Tools zur Messung der Code Coverage verwendet. Für Android ist der Standard JaCoCo (Java Code Coverage), das sich in Gradle integriert und sowohl Unit-Tests als auch Instrumentierungstests unterstützt. Für iOS wird XCCov verwendet, das in Xcode integriert ist.

JaCoCo für Android

JaCoCo erstellt Berichte in den Formaten HTML, XML und CSV. Der HTML-Bericht hebt Zeilen visuell hervor: grün — ausgeführt, rot — übersprungen, gelb — teilweise ausgeführt. Der XML-Bericht ist mit SonarQube und anderen Code-Analyse-Systemen kompatibel. JaCoCo unterstützt Klassenfilterung: generierter Code, Data Binding und BuildConfig können ausgeschlossen werden.

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

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

XCCov für iOS

XCCov ist ein in Xcode integriertes Tool zur Messung der Codeabdeckung. Es wird über Gather coverage data im Testschema aktiviert. XCCov unterstützt die Abdeckung für Swift und Objective-C, erstellt Berichte im .xccovreport-Format und integriert sich über xcodebuild -enableCodeCoverage YES in CI. Daten werden auf der Konsole ausgegeben und können in JSON exportiert werden.

SonarQube und Codecov

Für die zentrale Überwachung der Abdeckung werden Plattformen wie SonarQube (Codequalitätsanalyse + Abdeckung), Codecov und Coveralls verwendet. Diese Dienste aggregieren Daten von JaCoCo und XCCov, zeigen Trends, Quality Gates und Integration mit GitHub/GitLab über PR-Kommentare.

Wie man die Codeabdeckung verbessert

Die Verbesserung der Code Coverage erfordert einen systematischen Ansatz: nicht „Prozentzahlen erhöhen“, sondern Risiken abdecken. Der erste Schritt ist die Analyse des JaCoCo- oder XCCov-Berichts — Identifizierung roter (nicht abgedeckter) Klassen. Priorität: Geschäftslogik → Repositories → ViewModel → UI-Komponenten.

TDD-Strategie

Test-Driven Development (TDD) stellt automatisch eine hohe Abdeckung sicher, da Tests vor der Implementierung geschrieben werden. Der Prozess: rot (fehlschlagenden Test schreiben) → grün (minimalen Code schreiben) → Refactoring. TDD diszipliniert den Entwickler und zwingt ihn, Grenzfälle und Ausnahmesituationen abzudecken, die oft ungetestet bleiben.

Parametrisierte Tests

Ein parametrisierter Test ersetzt Dutzende gewöhnlicher Tests. JUnit und XCTest unterstützen Parametrisierung: @ParameterizedTest in JUnit 5, XCTestCase mit testPerformanceExample in XCTest. Die Parametrisierung ermöglicht die Überprüfung vieler Eingabedaten ohne Code-Duplizierung, was die Zweig- und Bedingungsabdeckung erheblich erweitert.

// Parametrisierter Test in Kotlin mit 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)
}

Fehler beim Arbeiten mit Code Coverage

Der häufigste Fehler ist die Jagd nach der Prozentzahl ohne Analyse der Testqualität. Das Team beginnt, Tests um der Tests willen zu schreiben: getter und setter prüfen, Abdeckung auf verschiedenen Ebenen duplizieren, triviale Methoden testen. Dies ergibt eine hohe Prozentzahl, verbessert aber nicht die tatsächliche Qualität.

Falsches Sicherheitsgefühl

Eine hohe Code Coverage kann ein falsches Gefühl vermitteln, dass die Anwendung gut getestet ist. Ein Test kann eine Codezeile ausführen, aber die Korrektheit des Ergebnisses nicht überprüfen. Beispiel: Ein Test ruft eine Rabattberechnungsmethode auf, überprüft aber nicht den Betrag — die Zeile wird ausgeführt, die Abdeckung steigt, aber der Fehler wird nicht gefunden.

Grenzfälle ignorieren

Ein typischer Fehler ist es, nur den „Happy Path“ zu testen und Grenzfälle zu ignorieren: leere Listen, Nullwerte, Maximalzahlen, ungültige Formate. Die meisten Fehler treten an Grenzen und Ausnahmen auf. Branch Coverage hilft, übersehene Zweige zu identifizieren, garantiert aber nicht die Überprüfung von Grenzwerten.

Mutation Testing — Überprüfung der Testqualität

Mutation Testing ist eine Methode zur Bewertung der Testqualität, bei der Mutationen (künstliche Fehler) in den Quellcode eingefügt und geprüft wird, ob die Tests fehlschlagen. Pitest ist ein beliebtes Mutation-Testing-Tool für Java und Kotlin. Wenn Tests bei einer Mutation nicht fehlschlagen, überprüfen sie diese Bedingung nicht.

Funktionsweise von Pitest

Pitest erstellt Mutanten — modifizierte Kopien des Quellcodes, bei denen beispielsweise > durch >=, true durch false ersetzt oder ein Methodenaufruf entfernt wird. Dann werden für jeden Mutanten die Tests ausgeführt. Wenn die Tests bestehen — hat der Mutant überlebt, was bedeutet, dass die Tests dieses Szenario nicht abdecken. Wenn die Tests fehlschlagen — wurde der Mutant getötet, der Test ist gültig.

// 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
}

Mutationsarten

Pitest unterstützt viele Mutationsarten: Änderung bedingter Operatoren (== → !=, < → <=), Entfernen von Methodenaufrufen, Ersetzen von Rückgabewerten (true → false), Änderung arithmetischer Operationen (+ → -), Mutation von Inkrementen (i++ → i--). Je mehr Mutationsarten von den Tests getötet werden, desto zuverlässiger ist die Testsammlung.

Mutation Score Ziel

Der angestrebte Mutation Score liegt bei 80 % oder höher. Das bedeutet, dass 80 % der künstlichen Fehler von den Tests erkannt werden. Eine Code Coverage von 90 % garantiert nicht, dass Tests Fehler finden — Mutation Testing liefert eine objektivere Bewertung. Pitest kann als Quality Gate in CI integriert werden und den Build blockieren, wenn der Mutation Score unter die Schwelle fällt.

Integration von Code Coverage in CI/CD

Für die automatische Steuerung der Code Coverage in CI/CD werden Quality Gates verwendet — Schwellenwerte, bei deren Verletzung der Build als instabil markiert oder abgelehnt wird. SonarQube ermöglicht die Konfiguration eines Quality Gates basierend auf einer Kombination von Metriken: Abdeckung (≥80 %), Anzahl der Fehler, Sicherheitslücken und doppelter Code.

Einrichtung von Quality Gates in GitHub Actions

In GitHub Actions wird Code Coverage durch Aktionsschritte integriert: Tests mit Abdeckung ausführen → Bericht an Codecov hochladen → Schwelle prüfen. Codecov kommentiert automatisch PRs mit dem Abdeckungsdiff und zeigt, welche Zeilen sich geändert haben und wie sich dies auf den Gesamtprozentsatz ausgewirkt hat. Wenn die Abdeckung gefallen ist, wird der PR blockiert, bis zusätzliche Tests geschrieben werden.

# GitHub Actions — Coverage zu Codecov hochladen
- 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

Berichterstattung und Visualisierung

HTML-Berichte von JaCoCo und XCCov enthalten visuelle Hervorhebungen der Abdeckung: grün — ausgeführte Zeilen, rot — nicht ausgeführte. SonarQube zeigt zusätzlich die Abdeckung auf Datei-, Klassen-, Methoden- und Zeilenebene sowie den Verlauf der Abdeckungsänderungen über Sprints. Dies hilft bei Entscheidungen über Refactoring und das Hinzufügen von Tests.