Kotlin Academy · Lektion

DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen

Entwerfen Sie stabile DSL-APIs und testen Sie sie mit gut lesbaren Assertion-Blöcken.

DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen ist eine kostenlose Kotlin Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Kotlin Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Kotlin Academy-Kurs umfasst insgesamt 4 Lektionen.

Warum sich das Testen von DSLs unterscheidet

Eine DSL ist eine öffentliche API. Änderungen daran können jede Aufrufstelle im Benutzercode beschädigen. Beim Testen einer DSL müssen sowohl die von ihr erzeugte Ausgabe als auch die von ihr erzwungene Struktur überprüft werden – einschließlich der Tatsache, dass ungültige Konstrukte weiterhin Compilerfehler verursachen.

Die Ausgabe einer DSL testen

Der einfachste Test: Erstellen Sie ein Objekt mit der DSL und prüfen Sie das gerenderte Ergebnis oder den internen Zustand des Builders.

@Test
fun `div contains a paragraph`() {
    val result = html {
        body {
            div { p("Hi") }
        }
    }
    assertTrue(result.render().contains("<p>"))
}

Den Builder-Zustand testen

Anstatt den gerenderten String zu testen, testen Sie direkt den Objektgraphen des Builders. Dadurch sind die Tests robuster gegenüber Änderungen an der Formatierung:

@Test
fun `server config has correct port`() {
    val cfg = server {
        host = "example.com"
        port = 9090
    }
    assertEquals(9090, cfg.port)
    assertEquals("example.com", cfg.host)
}

Verschachtelte Strukturen testen

Durchlaufen Sie den Objektbaum, um die Verschachtelungsbeziehungen zu überprüfen:

@Test
fun `body contains one div`() {
    val page = html { body { div { } } }
    assertEquals(1, page.children
        .filterIsInstance<Body>().first()
        .children.filterIsInstance<Div>().size
    )
}

Tests von Compilerfehlern

Compilerfehler können Sie nicht direkt mit Unit-Tests testen. Sie können jedoch Kommentare wie // This should NOT compile hinzufügen und den fehlschlagenden Code auskommentiert lassen. Einige Projekte verwenden die Bibliothek Kotlin Compile Testing, um zu überprüfen, dass bestimmter Code NICHT kompiliert.

Eine DSL sicher weiterentwickeln: Ergänzende Änderungen

Das Hinzufügen neuer optionaler Parameter mit Standardwerten oder neuer Builder-Funktionen ist abwärtskompatibel. Bestehende Aufrufstellen kompilieren unverändert.

// Before
fun server(block: ServerConfig.() -> Unit): ServerConfig
// After — additive: new optional feature
fun server(enableMetrics: Boolean = false, block: ServerConfig.() -> Unit): ServerConfig

Breaking Change: Entfernen oder Umbenennen

Das Entfernen oder Umbenennen einer DSL-Funktion beschädigt Aufrufstellen. Wenn Sie eine Funktion umbenennen müssen, stellen Sie einen veralteten Alias bereit und entfernen Sie ihn in einer künftigen Hauptversion:

@Deprecated("Use database{} instead", ReplaceWith("database(block)"))
fun db(block: DbConfig.() -> Unit) = database(block)

Ihre DSL versionieren

Verwenden Sie für Bibliotheks-DSLs semantische Versionierung. Grundlegende Änderungen an der DSL – etwa entfernte Funktionen oder geänderte Receiver-Typen – erfordern eine Erhöhung der Hauptversionsnummer. Dokumentieren Sie diese Änderungen in einem Changelog.

Mit @RequiresOptIn für experimentelle DSL-Funktionen

Kennzeichnen Sie instabile DSL-Erweiterungen mit @RequiresOptIn. Benutzer entscheiden sich ausdrücklich für deren Verwendung und verlassen sich dadurch nicht versehentlich auf Funktionen, die sich ändern können:

@RequiresOptIn(message = "This DSL feature is experimental and may change")
annotation class ExperimentalDsl

@ExperimentalDsl
fun ServerConfig.enableDebug() { /*...*/ }

Property-Delegation in DSLs

DSLs können Property-Delegation verwenden, um erforderliche Felder zu erzwingen und klare Fehlermeldungen auszugeben, wenn ein erforderlicher Wert fehlt:

class Required<T> {
    private var value: T? = null
    operator fun getValue(t: Any?, p: KProperty<*>): T = value ?: error("${p.name} is required")
    operator fun setValue(t: Any?, p: KProperty<*>, v: T) { value = v }
}

Vertragstests über Versionen hinweg

Halten Sie eine Sammlung von „Golden“-DSL-Nutzungsbeispielen als Tests vor. Wenn ein Refactoring diese beschädigt, erkennt die Testsuite das, bevor es Benutzer tun. Gleichzeitig dienen diese Beispiele als lebende Dokumentation.

Schnelltest

Welche Art von DSL-Änderung ist für die Abwärtskompatibilität am sichersten?

Zusammenfassung: DSLs testen und weiterentwickeln

Wichtige Erkenntnisse:

Testen Sie in Unit-Tests sowohl die DSL-Ausgabe als auch den Objektzustand des Builders
Ergänzende Änderungen – neue optionale Funktionen oder Parameter – sind sicher
Verwenden Sie @Deprecated(ReplaceWith=...), um Funktionen umzubenennen, ohne Benutzer zu beeinträchtigen
Verwenden Sie @RequiresOptIn für experimentelle DSL-Funktionen
Halten Sie Golden-Usage-Tests vor, um Regressionen über mehrere Versionen hinweg zu erkennen

Häufig gestellte Fragen

Ist die Lektion „DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen“ kostenlos?

Ja — der vollständige Text von „DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Kotlin Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Kotlin Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen“?

Entwerfen Sie stabile DSL-APIs und testen Sie sie mit gut lesbaren Assertion-Blöcken. Du übst Kotlin Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Kotlin Academy zu starten?

Keine Vorkenntnisse erforderlich. Kotlin Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Kotlin Academy-Lektion Code schreiben und ausführen?

Ja. Jede Kotlin Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Lambda mit Receiver: Grundlage für DSLs
@DslMarker: Receiver-Leaks verhindern
Eine typsichere HTML-/Config-DSL erstellen
DSLs testen und weiterentwickeln, ohne Nutzer zu beeinträchtigen

← Zurück zu Kotlin Academy