Kotlin-Testen: Wo ein Anfänger beginnen sollte – ein vollständiger Leitfaden

Einleitung: Warum Kotlin-Testen eine Superkraft und keine langweilige Pflicht ist

Stellen Sie sich vor: Sie haben eine App in Kotlin geschrieben. Sie funktioniert. Sie sind glücklich. Aber eine Woche vergeht, Sie fügen eine neue Funktion hinzu – und plötzlich geht die alte kaputt. Kommt Ihnen das bekannt vor? Wenn nicht, sind Sie entweder ein Genie oder haben noch nie Code ohne Tests geschrieben. Kotlin-Testen ist nicht nur ein Häkchen auf der Checkliste eines Entwicklers. Es ist Ihr persönlicher „Schutzschild“ gegen Bugs, eine Möglichkeit, nach dem Deployment ruhig zu schlafen, und ein Werkzeug, das den Code sauberer und verständlicher macht.

In diesem Artikel zeige ich Ihnen, wo ein Anfänger-Entwickler mit dem Testen in Kotlin beginnen kann. Wir behandeln reale Beispiele, beliebte Bibliotheken und Lifehacks, die Ihnen Stunden des Debuggings ersparen. Sie erfahren, wie Sie Unit-Tests schreiben, Abhängigkeiten mocken und Coroutinen testen. Los geht's!

Schritt 1: Einrichtung der Umgebung – die ersten 5 Minuten

Bevor Sie den ersten Test schreiben, müssen Sie Abhängigkeiten einbinden. Wenn Sie Gradle verwenden (und das tun Sie höchstwahrscheinlich), fügen Sie die folgenden Zeilen in Ihre build.gradle.kts ein:

// build.gradle.kts\ndependencies {\n    // JUnit 5 – die Grundlage von Unit-Tests\n    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")\n    \n    // MockK – die beste Bibliothek für Mocks in Kotlin\n    testImplementation("io.mockk:mockk:1.13.8")\n    \n    // AssertJ – schöne und lesbare Assertions\n    testImplementation("org.assertj:assertj-core:3.24.2")\n    \n    // Zum Testen von Coroutinen\n    testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3")\n}\n\ntasks.test {\n    useJUnitPlatform()\n}

Fertig! Jetzt haben Sie alles, was Sie zum Schreiben von Tests benötigen. Beachten Sie: Wir verwenden JUnit 5 (nicht 4) – das ist der moderne Standard, der hervorragend mit Kotlin harmoniert. MockK wurde nicht zufällig gewählt: Es versteht null-safety, Extension-Funktionen und andere Kotlin-Features, mit denen Mockito schlecht zurechtkommt.

Schritt 2: Ihr erster Unit-Test in Kotlin

Lassen Sie uns eine einfache Klasse schreiben und testen. Nehmen wir an, wir haben einen Rabattrechner:

// DiscountCalculator.kt\nclass DiscountCalculator {\n    fun calculateDiscount(price: Double, discountPercent: Int): Double {\n        require(price >= 0) { "Der Preis darf nicht negativ sein" }\n        require(discountPercent in 0..100) { "Der Rabatt muss zwischen 0 und 100 liegen" }\n        return price * (100 - discountPercent) / 100.0\n    }\n}

Jetzt schreiben wir den Test. Erstellen Sie eine Datei DiscountCalculatorTest.kt im Ordner src/test/kotlin:

import org.junit.jupiter.api.Test\nimport org.junit.jupiter.api.assertThrows\nimport org.assertj.core.api.Assertions.assertThat\n\nclass DiscountCalculatorTest {\n    \n    private val calculator = DiscountCalculator()\n    \n    @Test\n    fun `sollte 20% Rabatt korrekt berechnen`() {\n        val result = calculator.calculateDiscount(1000.0, 20)\n        assertThat(result).isEqualTo(800.0)\n    }\n    \n    @Test\n    fun `sollte eine Ausnahme bei negativem Preis werfen`() {\n        assertThrows<IllegalArgumentException> {\n            calculator.calculateDiscount(-100.0, 10)\n        }\n    }\n    \n    @Test\n    fun `sollte den vollen Preis bei 0% Rabatt zurückgeben`() {\n        val result = calculator.calculateDiscount(500.0, 0)\n        assertThat(result).isEqualTo(500.0)\n    }\n}

Beachten Sie den Stil: Wir verwenden Backticks für die Testnamen auf Deutsch (Kotlin erlaubt das). Das macht die Tests auch für nicht-technische Kollegen lesbar. AssertJ bietet eine fließende Schnittstelle: assertThat(result).isEqualTo(800.0) – liest sich wie ein englischer Satz.

Schritt 3: Mocks mit MockK – wenn wir Abhängigkeiten testen

In realen Anwendungen leben Klassen selten für sich allein. Sie greifen auf Datenbanken, APIs oder andere Dienste zu. Um nicht von externen Systemen abhängig zu sein, verwenden wir Mocks. Nehmen wir an, wir haben einen Dienst, der