Tests mit KI generieren lassen: Worauf achten

1. KI-generierte Tests als Ausgangspunkt, nicht als Ergebnis

Claude Code kann in Sekunden aus einer PHP-Klasse eine vollständige PHPUnit-Testklasse erzeugen, inklusive Mocks, Data Provider und Fixtures. Das spart echte Zeit beim lästigen Boilerplate: Setup-Methoden, Konstruktor-Aufrufe mit allen Pflichtabhängigkeiten, Namensgebung nach PSR-Konvention. Wer diesen Schritt bisher manuell erledigt hat, gewinnt dadurch spürbar Geschwindigkeit, besonders bei Legacy-Klassen ohne jede bestehende Testabdeckung.

Der Denkfehler entsteht, wenn dieser Geschwindigkeitsgewinn mit Qualität verwechselt wird. Eine generierte Testklasse, die grün läuft, beweist nur, dass die Assertions zum aktuellen Codeverhalten passen, nicht, dass dieses Verhalten korrekt ist. Der eigentliche Wert von Tests liegt darin, künftige Änderungen gegen eine Spezifikation abzusichern, und genau diese Spezifikation kennt die KI nur, wenn sie ihr explizit mitgegeben wird. Ohne Kontext bleibt jeder generierte Test ein Vorschlag, der Prüfung durch einen Entwickler mit Fachwissen über die eigentliche Anforderung braucht.

2. Das Kernproblem: Ist-Verhalten statt Soll-Verhalten testen

Wenn ein Sprachmodell eine Testsuite für eine bestehende Methode generiert, beobachtet es typischerweise, was der Code aktuell zurückgibt, und schreibt eine Assertion, die genau das bestätigt. Bei einer fehlerfreien Methode ist das unproblematisch. Bei einer Methode mit einem Bug wird der Bug jedoch zur festgeschriebenen Erwartung: Der Test wird künftig fehlschlagen, sobald jemand den Bug korrigiert, weil die Korrektur formal als Regression erscheint.

Dieses Muster ist besonders tückisch, weil die betroffenen Tests auf den ersten Blick völlig normal aussehen, vollständig grün laufen und die Coverage-Zahl erhöhen. Erst ein Abgleich mit der eigentlichen fachlichen Anforderung, etwa einem Ticket, einer Dokumentation oder einer bewussten Rückfrage an den Fachbereich, deckt auf, dass ein Test das falsche Verhalten zementiert. Entwickler, die KI-generierte Tests einsetzen, brauchen deshalb für jede nicht triviale Methode eine bewusste Antwort auf die Frage, was die Methode laut Spezifikation tun soll, bevor sie eine Assertion akzeptieren.

# Claude Code test generation and verification loop
claude "Generate PHPUnit tests for src/app/code/Mironsoft/Pricing/Model/TierPriceCalculator.php.
Cover null price, negative quantity, and currency rounding edge cases."

# Never trust generated tests blindly - run them first
bin/cli vendor/bin/phpunit app/code/Mironsoft/Pricing/Test/Unit/TierPriceCalculatorTest.php --testdox

# Then check what the tests actually assert, not just whether they pass
bin/cli vendor/bin/phpunit --coverage-text app/code/Mironsoft/Pricing/Test/Unit/TierPriceCalculatorTest.php

3. Wie Claude Code Tests generiert: Kontext, Prompts, Beispiele

Die Qualität generierter Tests hängt direkt vom mitgegebenen Kontext ab. Ein Prompt, der nur den Dateipfad nennt, liefert im besten Fall Tests für den Happy Path. Ein Prompt, der die Geschäftsregel, bekannte Randfälle und das erwartete Fehlerverhalten explizit benennt, liefert deutlich gezieltere Tests. Claude Code kann dabei bestehenden Code, verlinkte Tickets und sogar die Commit-Historie einer Datei einbeziehen, wenn diese Informationen zugänglich sind.

In der Praxis funktioniert ein zweistufiger Ansatz am zuverlässigsten: Zuerst wird die fachliche Spezifikation in Textform formuliert, etwa als Liste von Regeln und Randfällen. Danach generiert die KI Tests gegen diese Spezifikation, nicht gegen den bestehenden Code. Dieser Umweg über eine explizite Beschreibung verhindert, dass die KI stillschweigend vom beobachteten Verhalten auf die Erwartung schließt, und macht die generierten Tests deutlich robuster gegenüber späteren Refactorings.

final class TierPriceCalculatorTest extends TestCase
{
    // WRONG: generated from observing the current (buggy) output.
    // The calculator currently returns a rounded-down price for negative
    // quantities, which is not the intended business rule - it merely
    // reflects a bug that a generator will happily lock in as "expected".
    public function testCalculatePriceWithNegativeQuantityReturnsZero(): void
    {
        $calculator = new TierPriceCalculator();
        $result = $calculator->calculate(19.99, -5);
        self::assertSame(0.0, $result); // asserts the bug, not the spec
    }

    // RIGHT: derived from the actual business rule in the ticket/spec,
    // independent of what the current implementation happens to return.
    public function testCalculateThrowsOnNegativeQuantity(): void
    {
        $calculator = new TierPriceCalculator();
        $this->expectException(InvalidArgumentException::class);
        $calculator->calculate(19.99, -5);
    }
}

4. Coverage-Zahlen richtig lesen: echte Edge Cases vs. Padding

Eine hohe Zeilenabdeckung sagt wenig darüber aus, ob die Tests tatsächlich etwas prüfen. KI-Modelle neigen dazu, für jede Codezeile mindestens eine Assertion zu erzeugen, auch wenn diese Assertion trivial ist, etwa assertInstanceOf für ein Objekt, das gar nicht scheitern kann, oder assertTrue(true) als reiner Lückenfüller, um eine Testmethode formal abzuschließen. Solche Zeilen zählen für die Coverage-Metrik, verbessern aber nicht die Fähigkeit der Suite, echte Fehler zu erkennen.

Echte Edge Cases betreffen Grenzwerte, ungültige Eingaben, leere Collections, Nebenläufigkeit und Fehlerpfade, also genau die Stellen, an denen Produktionscode tatsächlich bricht. Wer eine generierte Testsuite bewertet, sollte deshalb nicht nur die Coverage-Prozentzahl ansehen, sondern gezielt nachfragen: Welche dieser Tests würden fehlschlagen, wenn ich absichtlich einen Bug einbaue? Tests, die bei jeder denkbaren Codeänderung weiterhin grün bleiben, sind reines Padding und liefern keinen Sicherheitsgewinn.

{
  "file": "Model/TierPriceCalculator.php",
  "line_coverage": "96.4%",
  "mutation_score": "38.2%",
  "mutants_total": 47,
  "mutants_killed": 18,
  "mutants_escaped": 29,
  "assessment": "high line coverage but low mutation score indicates assertions that do not verify actual behavior, a typical signature of AI-generated padding tests"
}

5. Magento-spezifisch: Unit-, Integrations- und API-Tests

In Magento-Projekten generiert Claude Code zuverlässig Unit-Tests für ViewModels und Service-Klassen mit klaren, injizierten Abhängigkeiten, weil sich diese gut mocken lassen. Schwieriger wird es bei Integrationstests, die eine echte Datenbankverbindung, Fixtures und die Magento-Objektmanager-Konfiguration benötigen. Hier muss die generierte Testklasse mit den korrekten XML-Fixtures aus dev/tests/integration/testsuite verknüpft werden, sonst schlägt der Test aus rein technischen Gründen fehl, unabhängig von der eigentlichen Fachlogik.

Für Repositories und Plugins ist besondere Vorsicht geboten: Ein von der KI generierter Mock für ein Repository-Interface gibt standardmäßig oft nur den Erfolgsfall zurück und lässt Fehlerpfade wie NoSuchEntityException komplett aus. Gerade Plugins, die vor oder nach einer Kernmethode eingreifen, brauchen Tests, die auch prüfen, was passiert, wenn die umschlossene Methode selbst eine Exception wirft. Diese Fälle generiert eine KI nur zuverlässig, wenn sie explizit danach gefragt wird.

6. Der Review-Prozess: Was Entwickler bei KI-Tests prüfen müssen

Ein strukturierter Review einer KI-generierten Testsuite unterscheidet sich vom klassischen Code-Review, weil nicht die Implementierung, sondern die Erwartungshaltung geprüft wird. Die zentrale Frage bei jeder Assertion lautet: Steht dieser erwartete Wert in der Spezifikation, oder wurde er einfach vom aktuellen Codeverhalten übernommen? Bei jeder Unsicherheit lohnt sich der Blick in das zugehörige Ticket oder eine kurze Rückfrage an den Fachbereich, bevor der Test gemergt wird.

Ein zweiter Prüfpunkt betrifft fehlende Fälle. Da eine KI naturgemäß nur das testet, worüber sie informiert ist oder was der Code sichtbar macht, fehlen häufig Tests für Zustände, die im Code nicht explizit behandelt werden, etwa Nebenläufigkeit, Zeitzonenprobleme oder Race Conditions bei parallelen Bestellungen. Eine kurze Checkliste mit den bekannten Risikobereichen des jeweiligen Moduls hilft, diese Lücken systematisch zu schließen, statt sich allein auf die generierte Suite zu verlassen.

#!/usr/bin/env python3
"""Flag AI-generated test files with high coverage but low mutation score."""
import json
import sys

COVERAGE_THRESHOLD = 80.0
MUTATION_THRESHOLD = 60.0


def flag_padding(report_path):
    with open(report_path, encoding="utf-8") as handle:
        report = json.load(handle)

    flagged = []
    for entry in report["files"]:
        coverage = entry["line_coverage_percent"]
        mutation = entry["mutation_score_percent"]
        # High coverage with a much lower mutation score is the classic
        # signature of tests that assert output without checking behavior.
        if coverage >= COVERAGE_THRESHOLD and mutation < MUTATION_THRESHOLD:
            flagged.append(entry["file"])

    return flagged


if __name__ == "__main__":
    for path in flag_padding(sys.argv[1]):
        print(f"[REVIEW] possible padding test: {path}")

7. Mutation Testing als Gegenprobe zur Testqualität

Mutation Testing beantwortet genau die Frage, die reine Coverage-Zahlen offenlassen: Erkennt die Testsuite tatsächlich Fehler? Ein Mutation-Testing-Tool wie Infection verändert den Produktionscode systematisch in kleinen Schritten, etwa durch Umkehren eines Vergleichsoperators oder Ändern einer Konstante, und prüft, ob mindestens ein Test dadurch fehlschlägt. Schlägt kein Test fehl, ist der veränderte Codeabschnitt effektiv ungetestet, unabhängig davon, was die Coverage-Zahl behauptet.

Für KI-generierte Testsuiten ist diese Gegenprobe besonders wertvoll, weil Mutation Testing Padding-Tests zuverlässig entlarvt. Eine Suite mit 95 Prozent Zeilenabdeckung, aber nur 40 Prozent Mutation Score zeigt klar, dass ein großer Teil der Assertions keine echte Prüfung darstellt. In der Praxis lohnt es sich, Infection als festen Bestandteil der CI-Pipeline für neue, KI-generierte Testdateien laufen zu lassen und einen Mindest-Score als Merge-Kriterium zu definieren.

8. Regressions-Fallen: Wenn Tests brechende Änderungen nicht erkennen

Der praktische Schaden falscher Assertions zeigt sich meist erst Monate später, wenn ein anderer Entwickler den ursprünglichen Bug korrigiert und dabei einen vermeintlich bestandenen Test zum Scheitern bringt. In diesem Moment entsteht typischerweise Verwirrung: Der Test wird als Regression interpretiert, und die eigentlich korrekte Bugfix-Änderung wird zurückgerollt oder der Test einfach angepasst, ohne die tiefere Ursache zu klären.

Um diese Falle zu vermeiden, hilft eine klare Namenskonvention und Dokumentation direkt im Test: Jede Assertion, die auf einer expliziten fachlichen Regel beruht, sollte einen Kommentar mit Verweis auf die Quelle enthalten, etwa das Ticket oder die Spezifikation. Assertions ohne diesen Bezug sollten im Review kritisch hinterfragt werden, bevor sie in die Suite aufgenommen werden. Diese Disziplin macht spätere Refactorings sicherer, weil klar erkennbar ist, welche Erwartung bewusst gewählt wurde und welche nur den Status quo abbildet.

// WRONG: AI generated this assertion by running the function once
// and capturing whatever it happened to output, not from a spec.
test('formatPrice rounds down odd cents', () => {
  expect(formatPrice(19.995)).toBe('19.99'); // just mirrors a rounding bug
});

// RIGHT: assertion derived from the documented rounding rule
// (round half up to two decimals), independent of current output.
test('formatPrice rounds half up to two decimals', () => {
  expect(formatPrice(19.995)).toBe('20.00');
});

9. KI-generierte Tests im direkten Vergleich: Gut vs. Schlecht

Die folgende Übersicht zeigt anhand typischer Situationen aus der Magento-Praxis, wie sich problematische, am Ist-Zustand orientierte Tests von Tests unterscheiden, die tatsächlich das beabsichtigte Verhalten absichern.

In allen fünf Beispielen liegt der Unterschied nicht in der Testsyntax, sondern im gedanklichen Ausgangspunkt: Wurde die Assertion aus dem beobachteten Verhalten abgeleitet oder aus der Spezifikation? Diese Unterscheidung lässt sich nicht automatisieren, sie erfordert bei jedem generierten Test eine bewusste, kurze Prüfung durch einen Menschen mit Fachwissen über die eigentliche Anforderung.

10. Zusammenfassung

KI-generierte Tests mit Claude Code sind ein wirkungsvoller Ausgangspunkt, kein fertiges Ergebnis. Sie sparen Zeit bei Boilerplate, Mocks und Fixtures, ersetzen aber nicht die fachliche Entscheidung darüber, was ein Test eigentlich prüfen soll. Das größte Risiko liegt darin, dass generierte Assertions oft den aktuellen, möglicherweise fehlerhaften Codezustand bestätigen, statt die eigentliche Spezifikation abzusichern, ein Muster, das erst bei einer späteren Bugfix-Änderung sichtbar wird.

Wer KI-generierte Tests systematisch bewertet, prüft Coverage-Zahlen kritisch, setzt Mutation Testing als Gegenprobe ein und dokumentiert die fachliche Quelle jeder nicht trivialen Assertion. So wird aus einem schnellen ersten Entwurf eine belastbare Testsuite, die tatsächlich vor Regressionen schützt, statt nur eine grüne CI-Pipeline vorzutäuschen.

11. FAQ: Tests mit KI generieren lassen