Hauptgedanke

Ein Assistent, den man um Tests bittet, nachdem die Funktion geschrieben ist, liefert Tests, die durchlaufen. Das ist zu erwarten: Er leitet sie aus dem ab, was er gerade geschrieben hat. Sie prüfen, dass die Funktion, mit diesem Argument aufgerufen, zurückgibt, was sie ohnehin zurückgibt, dass die Komponente anzeigt, was sie ohnehin anzeigt. Hat die Implementierung den Bedarf falsch verstanden, schreiben die Tests dieses Missverständnis fest und schützen es gegen jede künftige Korrektur.

Die sichtbare Wirkung ist das Gegenteil der tatsächlichen. Das Repository zeigt Hunderte grüner Tests, die Suite läuft bei jeder Änderung, und das Produkt wirkt abgesichert – obwohl nichts in dieser Vorkehrung den Code je dem Verhalten gegenübergestellt hat, das der Fachbereich erwartet.

Das unterscheidet eine Abdeckung von einer Teststrategie: Die erste misst, wie viel Code durchlaufen wird; die zweite entscheidet, welche Verhaltensweisen wahr bleiben müssen, auf welcher Ebene man sie prüft und welche Risiken abgedeckt sein müssen.

Warum das wichtig ist

Das verhindert, das Vorhandensein von Tests als Beweis zu lesen. Bei generiertem Code ist die Zahl der Tests die am leichtesten zu erreichende und am wenigsten aussagekräftige Größe: Man muss wissen, woher sie kommen – aus einer vorher formulierten Absicht oder aus einer nachträglich gelesenen Implementierung.

Es erklärt auch, warum das Thema für Produktleute schwierig ist. Sie haben nicht unbedingt Erfahrung mit testgetriebener Entwicklung, unterscheiden nicht immer zwischen Unit-Test, Integrationstest und End-to-End-Test und mussten nie eine Fachregel als Prüfung formulieren – sie haben also keine Möglichkeit zu erkennen, dass das, was sie zurückbekommen, ein Spiegel ist.

Nuancen und Grenzen

Ein nach dem Code geschriebener Test ist nicht wertlos: Er schützt vor Regressionen, und das ist bei Code, den man nicht liest, schon viel. Was er nicht leistet, ist der Nachweis, dass das Verhalten das richtige war.

Und die Reihenfolge umzukehren, reicht auch nicht: Ein vorher geschriebener Test von jemandem, der den Bedarf falsch verstanden hat, scheitert auf genau dieselbe Weise.

Offene Fragen

• Wie kann jemand, der nie getestet hat, eine fachliche Absicht in prüfbarer Form ausdrücken, ohne zuerst das Vokabular des Testens neu zu lernen?