KI-gestützte Teststrategien, die wirklich funktionieren

Es gibt ein wachsendes Narrativ, dass KI alle Tests für uns schreiben wird. Die Realität ist differenzierter. KI-Tools wie Claude Code können den Testing-Workflow drastisch verbessern, aber nur bei strategischem Einsatz. Blind generierte Tests erzeugen fragile, wertlose Test-Suiten, die falsches Vertrauen schaffen.

Dieser Beitrag behandelt die Strategien, die bei mir tatsächlich funktioniert haben — sinnvolle Testfälle generieren, KI-gestütztes TDD, Randfälle finden und Test-Suiten langfristig pflegen. Alle Beispiele nutzen TypeScript und Jest.

Testfälle aus Code generieren

Der einfachste Anwendungsfall: KI auf eine Funktion zeigen und Tests generieren lassen. Aber der Unterschied zwischen nützlichem und nutzlosem Output hängt komplett vom Prompt ab.

Schlechter Prompt: „Schreib Tests für diese Funktion."

Guter Prompt: „Schreib Tests für diese Funktion. Decke den Happy Path ab, null/undefined-Inputs, leere Arrays, Grenzwerte und Fehlerbedingungen. Jeder Test soll einen beschreibenden Namen haben, der das erwartete Verhalten erklärt."

Ein konkretes Beispiel: Gegeben eine paginate-Funktion, die ein Array paginiert und Metadaten wie totalPages, hasNext und hasPrev zurückgibt. KI generiert Tests, an die ein Mensch nicht sofort denkt:

describe('paginate', () => {
  it('gibt die korrekte Teilmenge für die erste Seite zurück', () => { /* ... */ });
  it('gibt die letzte partielle Seite korrekt zurück', () => { /* ... */ });
  it('gibt leere Daten für eine Seite jenseits des Totals zurück', () => { /* ... */ });
  it('behandelt ein leeres Array', () => { /* ... */ });
  it('behandelt pageSize größer als das Array', () => { /* ... */ });
  it('behandelt pageSize von 1', () => { /* ... */ });
});

Die Randfälle sind entscheidend: leeres Array, Seite jenseits des Totals, pageSize von 1, pageSize größer als der Datensatz. Das sind die Tests, die echte Bugs finden.

KI-gestütztes TDD

Hier glänzt KI am meisten. Statt Tests nach dem Code zu generieren, nutzt man KI für Tests vor der Implementierung.

Der Workflow:

1. Verhalten der Funktion in natürlicher Sprache beschreiben
2. KI die Test-Suite schreiben lassen
3. Tests reviewen und anpassen — das zwingt zum Nachdenken über die Spezifikation
4. Code implementieren, bis die Tests grün sind

Man beschreibt zum Beispiel eine Funktion parseTimeRange, die Strings wie 2h30m oder 45m in Sekunden umrechnet, und lässt KI die Tests schreiben. Beim Review fällt auf, dass man negative Werte nicht spezifiziert hat. Man ergänzt die Spec und implementiert dann. Die Tests werden zur Spezifikation — genau so, wie TDD funktionieren soll, nur schneller.

Randfälle finden, die Menschen übersehen

Menschen denken in Happy Paths. Wir schreiben den Test für den erwarteten Input, prüfen ob er funktioniert, und machen weiter. KI denkt anders — sie betrachtet systematisch Input-Kategorien:

• Grenzwerte: 0, -1, MAX_SAFE_INTEGER, leere Strings, einzelne Zeichen
• Type-Coercion-Fallen: "0" vs 0, null vs undefined, NaN
• Unicode und Encoding: Emoji in String-Inputs, Multi-Byte-Zeichen
• Nebenläufigkeit: Was passiert bei gleichzeitigen Aufrufen? Ist die Funktion idempotent?
• Zustandsabhängigkeiten: Verhält sich die Funktion beim zweiten Aufruf anders?

Ich frage regelmäßig: „Welche Randfälle fehlen mir in dieser Testdatei?" Meistens findet die KI zwei oder drei, die ich nicht bedacht hatte.

Property-Based Testing mit KI

Property-Based Testing ist untergenutzt, weil das Schreiben von Generatoren und Properties schwieriger ist als beispielbasierte Tests. KI senkt diese Hürde erheblich.

import fc from 'fast-check';

describe('paginate properties', () => {
  it('Datenlänge überschreitet nie pageSize', () => {
    fc.assert(
      fc.property(
        fc.array(fc.integer()),
        fc.integer({ min: 1, max: 1000 }),
        fc.integer({ min: 1, max: 100 }),
        (items, page, pageSize) => {
          const result = paginate(items, page, pageSize);
          expect(result.data.length).toBeLessThanOrEqual(pageSize);
        }
      )
    );
  });
});

KI-generierte Property-Tests sind überraschend gut. Properties beschreiben Invarianten — Dinge, die unabhängig vom Input immer wahr sein müssen. KI ist effektiv darin, diese zu identifizieren, weil sie über den Vertrag der Funktion nachdenken kann.

Test-Wartung und Refactoring

Tests verrotten. Wenn sich die Implementierung ändert, brechen Tests — nicht wegen Bugs, sondern weil der Test an Implementierungsdetails gekoppelt war. KI hilft hier auf zwei Arten:

1. Fragile Tests identifizieren: KI bitten, die Testdatei zu reviewen und Tests zu markieren, die von Implementierungsdetails statt Verhalten abhängen. Tests, die interne Methoden mocken oder Aufrufzähler prüfen, sind Kandidaten fürs Refactoring.

2. Tests beim Refactoring aktualisieren: Wenn man die Signatur oder das Verhalten einer Funktion ändert, kann KI die zugehörigen Tests anpassen. Das ist schneller als manuelles Aktualisieren und weniger fehleranfällig.

Integration vs. Unit Testing

KI ist ausgezeichnet bei Unit-Tests, weil der Scope klein und der Vertrag klar ist. Integrationstests sind schwieriger, weil sie Verständnis von Systemgrenzen, externen Abhängigkeiten und Umgebungskonfiguration erfordern.

Meine Empfehlung: KI aggressiv für Unit-Tests einsetzen. Für Integrationstests die Struktur generieren lassen — describe-Blöcke, Setup/Teardown, Testnamen — und die Assertions manuell ergänzen.

Ehrliche Limitierungen

KI-generierte Tests haben echte Grenzen:

• Sie testen, was der Code tut, nicht was er soll: Wenn die Implementierung einen Bug hat, schreibt KI möglicherweise Tests, die das fehlerhafte Verhalten verifizieren.
• Coverage-Theater: KI kann 100% Code-Coverage mit Tests erreichen, die nichts Sinnvolles prüfen.
• Flaky-Test-Generierung: KI erzeugt manchmal Tests mit Timing-Abhängigkeiten oder hartcodierten Daten.
• Over-Mocking: KI neigt zu aggressivem Mocking. Wenn jede Dependency gemockt ist, testet man die Mocks, nicht den Code.

Praktische Strategie-Zusammenfassung

1. KI für TDD nutzen: Tests zuerst schreiben, dann implementieren. KI die initiale Test-Suite aus natürlicher Sprache generieren lassen.
2. Generierte Tests immer reviewen: KI-generierte Tests wie KI-generierten Code behandeln — nützlicher Startpunkt, kein fertiges Produkt.
3. Explizit nach Randfällen fragen: „Welche Randfälle fehlen mir?" ist der wertvollste Testing-Prompt.
4. Property-Based Testing für Utilities: KI macht das Schreiben von Properties und Generatoren deutlich schneller.
5. Unit- und Integrationsstrategien trennen: KI ist stark bei Unit-Tests, unterstützend bei Integrationstests.
6. Mutation Testing einsetzen: Die ultimative Prüfung. Wenn Tests bei mutiertem Code immer noch bestehen, testen sie nicht das Richtige. Tools wie Stryker helfen hier.

Testing ist der Bereich, in dem KI den klarsten, messbarsten Mehrwert liefert. Nicht weil sie perfekte Tests schreibt, sondern weil sie die Tests schreibt, die man übersprungen hätte — die Randfälle, die Grenzwerte, die Fehlerpfade. Kombiniert mit menschlichem Review ist das eine Teststrategie, die tatsächlich funktioniert.