Code-Abdeckung in Kotlin: Von 0 auf 80 % an einem Abend

Einleitung: Warum „grüne“ Tests eine Illusion sind?

Sie führen Tests aus, sehen den ersehnten grünen Balken und fühlen sich wie ein Superheld. Aber was, wenn ich Ihnen sage, dass Ihre Tests nutzlos sein könnten? Dass sie nur eine von zehn Zeilen prüfen, während die anderen neun eine „tote Zone“ sind, in der Bugs leben? Genau hier kommt die Code-Abdeckung (code coverage) ins Spiel. Es sind nicht nur Zahlen für einen Bericht, sondern Ihr persönliches Radar, das anzeigt, wie gut die Tests Ihren Kotlin-Code „abdecken“.

In diesem Artikel werden wir untersuchen, wie Sie die Code-Abdeckung in Kotlin von einer langweiligen Metrik in ein leistungsstarkes Werkzeug verwandeln. Sie erfahren, welche Tools wirklich funktionieren, was die Prozentzahlen bedeuten und wie Sie nicht in die Falle der „100 % Abdeckung“ tappen. Los geht's!

Was ist Code-Abdeckung und warum ist sie für Kotlin wichtig?

Stellen Sie sich vor, Ihr Code ist ein Golfplatz und die Tests sind die Spieler. Die Code-Abdeckung ist eine Karte, die zeigt, welche Bereiche des Platzes die Spieler betreten haben. Wenn die Spieler einen gefährlichen Bunker (komplexen Algorithmus) umgehen, erfahren Sie das.

In der Welt von Kotlin, wo wir oft Coroutinen, sealed classes und extension-Funktionen verwenden, können naive Tests leicht ganze Logikzweige übersehen. Abdeckungsmetriken helfen, drei Fragen zu beantworten:

\n
• Wie viel Prozent der Codezeilen wurden während der Tests ausgeführt?
\n
• Welche Bedingungen (if/else, when) wurden überprüft?
\n
• Welche Funktionen blieben unbeachtet?
\n

Ohne diese Metriken riskieren Sie, Code in die Produktion zu bringen, der „nur montags“ funktioniert.

Tools zur Messung der Abdeckung in Kotlin: Die Top 3

Im Kotlin-Ökosystem gibt es drei Hauptakteure, die Ihnen helfen, die code coverage zu messen. Lernen wir jeden kennen.

1. JaCoCo (Java Code Coverage) – Der Veteran

Das beliebteste Tool. Es arbeitet auf Bytecode-Ebene und eignet sich daher sowohl für Java als auch für Kotlin. Sein größter Vorteil ist die umfangreiche Statistik und die Integration in CI/CD.

Einbindung in Gradle (Kotlin DSL):

plugins {\n    id("jacoco")\n}\n\ntasks.jacocoTestReport {\n    dependsOn(tasks.test) // Tests vor dem Bericht ausführen\n    reports {\n        xml.required.set(true)\n        html.required.set(true) // Generiert einen schönen HTML-Bericht\n    }\n}

Nach dem Ausführen von ./gradlew jacocoTestReport erhalten Sie eine HTML-Datei, in der nicht abgedeckte Zeilen rot markiert sind. Praktisch, oder?

2. Kover – Der moderne Spieler

Speziell für Kotlin entwickelt. Im Gegensatz zu JaCoCo arbeitet Kover auf AST-Ebene (Abstrakter Syntaxbaum), was es für Kotlin-spezifische Konstrukte (z. B. inline-Funktionen) genauer macht.

Einbindung von Kover:

plugins {\n    id("org.jetbrains.kotlinx.kover") version "0.7.3"\n}\n\nkover {\n    excludeSourceSets {\n        names("test") // Tests selbst aus dem Bericht ausschließen\n    }\n}

Kover generiert Berichte in den Formaten HTML, XML und sogar als Badges für GitHub. Es ist die ideale Wahl für reine Kotlin-Projekte.

3. IntelliJ IDEA Coverage – Für schnelle Überprüfungen

Ein integriertes Tool. Sie führen Tests mit Abdeckung aus (grünes Symbol „Run with Coverage“) und sehen den farblich markierten Code direkt in der IDE. Praktisch für die lokale Entwicklung, aber nicht für CI.

Tipp: Verwenden Sie IntelliJ für schnelle Iterationen und JaCoCo oder Kover für den endgültigen Bericht.

Code-Abdeckungsmetriken: Was bedeuten diese Prozentzahlen?

Wenn Sie „80 % Abdeckung“ sehen, klingt das cool. Aber 80 % wovon? Lassen Sie uns die wichtigsten Metriken durchgehen, die alle Tools ausgeben.

Line Coverage (Zeilenabdeckung)

Die einfachste Metrik. Wie viele Zeilen des Quellcodes wurden von den Tests berührt. Wenn eine Zeile kein einziges Mal ausgeführt wurde, gilt sie als nicht abgedeckt.

Beispiel:

fun process(value: Int): String {\n    if (