Was Test-Driven Development beweisen kann und was nicht

Test-Driven Development (TDD) entwickelt Software in kurzen Feedback-Zyklen. Ein Entwickler schreibt einen Test für das nächste Verhalten, sieht ihn fehlschlagen, implementiert gerade genug Code für einen erfolgreichen Test und refaktoriert anschließend bei weiterhin grüner Suite. So können Annahmen und erwartetes Verhalten früh sichtbar werden. Die Methode macht Software weder fehlerfrei noch ersetzt sie andere Kontrollen eines Produktionssystems.

Was der TDD-Zyklus tatsächlich verspricht

Martin Fowler beschreibt den Kernzyklus so: einen Test für die nächste Funktion schreiben, funktionalen Code bis zum erfolgreichen Test erstellen und den Code anschließend klarer strukturieren. Teams fassen das als Red, Green, Refactor zusammen. Der Test sollte zuerst aus einem aussagekräftigen Grund fehlschlagen. Andernfalls zeigt ein grünes Ergebnis womöglich nur, dass der Test das beabsichtigte Verhalten nie ausgeführt hat.

TDD ist eine Entwicklungsdisziplin, keine Coverage-Garantie. Entwickler können wichtige Szenarien auslassen, das falsche Ergebnis prüfen, eine riskante Integration wegmocken oder eine fehlerhafte Anforderung perfekt bewahren. Die belastbare Aussage ist enger: Verhalten, das ein sinnvoller Test abbildet, kann bei zuverlässiger Ausführung schnelles Regression-Feedback erhalten.

Die berühmte Motte war nicht der Ursprung des Wortes

1947 fanden Ingenieure am Harvard Mark II eine Motte in einem Bauteil und klebten sie mit dem Hinweis „first actual case of bug being found“ in das Logbuch. Grace Hopper gehörte zu den Personen, die mit dem Mark-II-Team arbeiteten. Die Episode machte die Computerbegriffe „bug“ und „debug“ bekannter, erfand das Wort „bug“ aber nicht. Das erhaltene Logbuch lässt sich nicht sicher Hopper persönlich zuschreiben.

Der Mark-II-Mottenfund wurde 1947 dokumentiert.

Wo TDD helfen kann

TDD ist besonders nützlich, wenn ein Team Verhalten als kleine, deterministische Beispiele ausdrücken kann. Es kann Schnittstellen klären, problematische Kopplung sichtbar machen, sicheres Refactoring unterstützen und bereits korrigiertes Verhalten automatisiert überprüfen. Zudem liefert es konkretes Material für Code Reviews: Prüfer können beschriebenes Verhalten, Implementierung und nicht abgedeckte Grenzen vergleichen.

Das wirtschaftliche Ergebnis hängt vom Kontext ab. TDD verlangt Design- und Wartungsaufwand, und eine fragile oder langsame Suite kann selbst zum Lieferkostenfaktor werden. Ob es Geld spart, hängt von Fehlerrisiko, Änderungshäufigkeit, Systemlebensdauer, Testumfang, Feedbackgeschwindigkeit und Fehlerkosten ab. Ein seriöser Business Case misst entkommene Fehler, Lead Time, Flaky-Test-Rate, Suite-Dauer, Wartungsaufwand und Recovery-Ergebnisse, statt eine allgemeine Einsparung zu versprechen.

"Nutze Tests, um wichtige Annahmen ausführbar zu machen, und prüfe anschließend die Risiken, die diese Tests nicht abdecken können."

Warum bestandene Tests keine Korrektheit beweisen

Eine Test-Suite bewertet ausgewählte Eingaben und erwartete Ergebnisse. Sie kann die Abwesenheit von Fehlern nicht allein beweisen. Eine grüne Suite kann Parallelitätsfehler, fehlerhafte externe Daten, Abhängigkeitsverhalten, Autorisierungslücken, Produktionskonfiguration oder falsche Geschäftsregeln übersehen. Auch Coverage-Prozente brauchen Interpretation: Die Ausführung einer Zeile zeigt nicht, dass jeder wichtige Zustandsübergang oder jede Invariante geprüft wurde.

Wähle Techniken nach Risiko. Unit Tests eignen sich für lokales Verhalten. Contract- und Integrationstests decken Komponentengrenzen ab. Property-based Tests und Fuzzing untersuchen nicht manuell aufgezählte Eingaben. Statische Analyse findet bestimmte Schwächeklassen ohne Programmausführung. Reviews, Threat Modeling, Penetrationstests, Betriebsmonitoring und Incident-Übungen adressieren andere Systemteile.

Was ändert sich bei Smart Contracts?

Smart Contracts können wertvolle Assets kontrollieren, öffentliche Einstiegspunkte anbieten, mit externen Contracts interagieren und unter protokollspezifischen Regeln arbeiten. Das erhöht die Kosten von Autorisierungs-, Accounting-, Oracle-, Upgrade- oder ökonomischen Designfehlern. Es macht TDD nicht zu einer vollständigen Sicherheitsmethode.

Für EVM-Systeme kann ein Produktionsplan beispielbasierte Unit Tests mit Invarianten- oder Property-Tests, Fuzzing, statischer Analyse, Fork-Netzwerk-Integrationstests, Access-Control-Review, Compiler- und Dependency-Prüfungen sowie manueller Bewertung von Geschäftslogik und ökonomischen Angriffen kombinieren. Frontends, APIs, Wallets, Indexer, Datenbanken und operative Kontrollen brauchen eigenen Testumfang. Ein Audit ist zusätzliche Evidenz, keine Garantie gegen Exploits.

Testaufwand und Fehlerkosten unterscheiden sich je System; die Grafik zeigt ein Konzept, keine gemessene Kurve.

Eine praktische Review-Checkliste

• Verhalten: Kann das Team wichtige Abnahmekriterien und Invarianten vor der Implementierung formulieren?
• Fehlermodi: Welche fehlerhaften Eingaben, ausgefallenen Abhängigkeiten, Berechtigungsfehler, Wiederholungen und Teilfehler sind relevant?
• Testgrenzen: Was ist real, gemockt, simuliert oder ausdrücklich außerhalb der Suite?
• Feedback: Läuft die Suite schnell und zuverlässig genug, um tägliche Entscheidungen zu beeinflussen?
• Sicherheit: Welche Risiken verlangen zusätzlich statische Analyse, Fuzzing, Review, Audit, Monitoring oder operative Kontrollen?
• Evidenz: Welche Launch Gates und Produktionssignale zeigen akzeptables Systemverhalten?

So bewertest du einen Engineering-Partner

Prüfe ein Team nicht mit einer ideologischen Einzelfrage wie der, ob es immer TDD nutzt. Bitte um die Teststrategie für deine konkreten Risiken. Eine glaubwürdige Antwort benennt Unit-Test-Umfang, benötigte Integrations- oder End-to-End-Evidenz, Darstellung externer Systeme, Umgang mit Flaky Tests, ergänzende Sicherheitstechniken und Evidenz, die einen Release blockiert.

Ein Projekt ohne automatisierte Tests scheitert nicht zwangsläufig, genauso wenig wie eine große Suite Erfolg garantiert. Entscheidend sind Risiko und Feedback. Teste Verhalten, dessen Fehler relevant ist, halte die Suite vertrauenswürdig und nutze ergänzende Kontrollen für das, was ein Test nicht beweisen kann.

Quellen

• Martin Fowler: Test-Driven Development
• Smithsonian National Museum of American History: Log Book With Computer Bug
• OWASP Smart Contract Security Testing Guide