Gute Tests zementieren keinen Slop: Verhalten statt Implementierung testen 2026

Die erste These aus dem viel diskutierten X Post von Sherwood lautet: Unit Tests zementieren Slop Code, weil sie ihn schwer änderbar machen. Die beste Antwort darauf kam aus den Kommentaren. Kevin (@kewun) hält dagegen, dass gute Unit Tests Verhalten prüfen und nicht die Implementierung. Genau dieser Unterschied entscheidet, ob Tests euren Agent bremsen oder schützen.

Der Unterschied in einem Satz

Ein Implementierungstest prüft, wie der Code arbeitet. Ein Verhaltenstest prüft, was dabei herauskommt. Der erste bricht bei jedem Umbau. Der zweite bricht nur, wenn sich wirklich etwas ändert.

Ein typischer Implementierungstest in PHPUnit sieht so aus:

$mailer = $this->createMock(Mailer::class);
$mailer->expects($this->once())->method('send');

$service = new OrderService($mailer, $repository);
$service->place($order);

Der Test weiß, dass intern ein Mailer genau einmal aufgerufen wird. Baut ein Agent den Service um und verschickt die Mail über ein Event, wird der Test rot. Obwohl sich für den Kunden nichts geändert hat.

Der Verhaltenstest dagegen fragt nach dem Ergebnis:

$service->place($order);

self::assertSame(OrderStatus::Placed, $repository->find($order->id)->status);
self::assertCount(1, $mailOutbox->sent());

Die Bestellung ist angelegt, eine Mail ist raus. Wie das intern passiert, ist egal. Ein Umbau bleibt grün, ein echter Fehler wird rot.

Warum das mit KI Agents doppelt zählt

Bricht ein Implementierungstest beim Refactoring, hat der Agent zwei Wege. Er macht den Umbau rückgängig, oder er passt den Test an. Meistens passt er den Test an. Danach ist der Test grün und wertlos, weil er nur noch den neuen Code beschreibt.

Das ist der Mechanismus hinter Sherwoods These. Nicht Tests an sich halten Slop fest, sondern Tests, die an Details kleben. Wie schnell so ein Umbau eine Applikation zerlegt, zeigt der Beitrag KI Refactoring zerstört die Applikation.

Woran ihr Slop Tests erkennt

• Mehr Mock Setup als Assertions: Der Test baut eine Welt aus Attrappen und prüft am Ende einen Aufruf.
• Rot bei Umbenennung: Eine private Methode bekommt einen neuen Namen, und der Test bricht.
• Aufrufe statt Ergebnisse: Assertions zählen, wie oft etwas passiert, statt was dabei herauskommt.
• Überlebende Mutanten: Infection verändert den Code, und der Test merkt es nicht.

Aufräumen in der richtigen Reihenfolge

Schritt	Was passiert	Warum
1. Messen	Mutation Testing über die Suite laufen lassen	Zeigt, welche Tests nichts schützen
2. Ergänzen	Verhaltenstest neben den alten Test schreiben	Die Logik bleibt durchgehend abgesichert
3. Löschen	Den Mock Test entfernen	Weniger Bruch bei jedem Umbau
4. Umbauen	Agent refactored in kleinen Schritten	Grüne Tests bestätigen jeden Schritt

Für alten Code ohne Tests ist Characterisation Testing mit Golden Master Tests der schnellste Einstieg. Wie der Umstieg von Mocks auf echte Tests in Symfony aussieht, zeigt Symfony Event Dispatcher mit PHPUnit testen. Für automatisierte Umbauten nutzen wir Rector, für alles Weitere hilft unser PHP Refactoring. Hintergrund zur Testklassifikation liefert The Practical Test Pyramid auf martinfowler.com.

Fazit

Sherwood hat recht, dass manche Tests Umbauten blockieren. Er zieht nur den falschen Schluss. Wer Implementierungstests durch Verhaltenstests ersetzt, bekommt beides: Freiheit beim Umbau und ein Netz, das echte Fehler fängt. Mehr dazu, welche Tests mit Agents bleiben sollten, steht in Die Testpyramide für KI Agents.

Häufige Fragen zu Verhaltenstests

Was ist 2026 der Unterschied zwischen Verhaltenstest und Implementierungstest?

Ein Verhaltenstest prüft das Ergebnis einer Aktion, etwa einen gespeicherten Status. Ein Implementierungstest prüft interne Abläufe, etwa wie oft eine Methode aufgerufen wird. Nur der erste übersteht ein Refactoring ohne Anpassung.

Halten Unit Tests 2026 schlechten KI Code fest?

Nur Tests, die an Details kleben. Sie brechen bei jedem Umbau, und der Agent passt sie dann an den neuen Code an. Verhaltenstests lassen Umbau zu und schlagen nur bei echten Änderungen an.

Sind Mocks 2026 grundsätzlich schlecht?

Nein. Für externe Systeme wie Zahlungsanbieter oder fremde APIs sind sie sinnvoll. Problematisch wird es, wenn eigene Klassen gemockt werden und der Test am Ende nur Aufrufe zählt.

Wie finde ich 2026 nutzlose Tests in meiner Suite?

Mit Mutation Testing. Infection verändert den Code gezielt und schaut, ob ein Test fehlschlägt. Überlebt eine Mutation, prüft der zugehörige Test zu wenig.

Darf ein KI Agent Tests selbst anpassen?

Nicht im selben Schritt wie den Code. Ändert der Agent Code und Test gleichzeitig, prüft niemand mehr das alte Verhalten. Teständerungen sollten immer ein Mensch freigeben.