TDD is dead. Long live testing. (Une contre-argumentation point à point à l'article phare de David Heinemeier Hansson, détracteur du Test-driven development)

Kernpunkte

1. Datum / Quelle. 7. Dezember 2022 (ursprünglich), 17. März 2025 (letzte Aktualisierung). Persönlicher Blog mathieueveillard.com. Kategorien: craft, best-of.
2. Autor. Mathieu Eveillard — Entwickler / Craft-Coach / Trainer.
3. Zielscheibe. DHH, "TDD is dead. Long live testing." (RailsConf 2014, Signal v Noise-Beitrag).
4. Zentrale These. TDD ist keine Religion, sondern ein Werkzeug. Und DHH kritisiert tatsächlich Test-first, nicht TDD. ### Eveillards zentrale Unterscheidung | Konzept | Definition | |---------|-----------| | Test-first | Ich schreibe alle Tests, bevor ich eine einzige Zeile Code schreibe | | Test-Driven Development | Tests leiten mich beim Schreiben von Code an — jedes Mal schreibe ich ein Stück Code als Reaktion auf einen neuen Test | > "Es ist schade, dass diese Verwechslung nie aufgeklärt wird, denn sie verdeckt eine völlig andere Art zu programmieren." ### Die 3 punktweisen Widerlegungen #### (1) "TDD als Hammer, um Ungläubige niederzuschlagen" DHH: TDD wird als Hammer benutzt, um auf Ungläubige zu zeigen, sie für unprofessionell zu erklären. Eveillard räumt ein: Es bringt nichts, mit dem Finger zu zeigen, das widerspricht der Demut des Craftsman. Definiert aber "guten Code" neu:
5. Über die reine Abwesenheit von Bugs hinaus;
6. Unit-Tests. , die das Verhalten auf niedrigster Ebene dokumentieren;
7. Direkt beim Code angesiedelt. (co-located);
8. Sicherheitsnetz. — "Je feiner die Maschen, desto besser werden Regressionen vermieden". #### (2) "Das Testspektrum vom Unit- zum System-Test verschieben" DHH: Verlagerung von Unit-Tests (mit Mocks) hin zu System-Tests. Eveillard entgegnet:
9. TDD verbietet nichts, was über Unit-Tests hinausgeht.
10. System-Tests ersetzen Unit-Tests nicht (eine Ende-zu-Ende getestete Steuererklärung = absurd).
11. Testpyramide. — jeder Typ trägt seinen eigenen Wert bei:
12. Unit-Tests = Feedback im Millisekundenbereich → leitet das Schreiben von Code via TDD an;
13. Frühe Fehlererkennung → geringere Kosten. Zur Architektur: "horrende Monstrositäten (Service Objects, Command Patterns)" — Eveillard beobachtet diese Effekte nicht in der funktionalen Programmierung, sodass sie eher der OOP zuzuschreiben sind, nicht TDD. #### (3) "Ich schreibe Software nicht test-first" DHH: verwendet "Test first", obwohl der Titel TDD ankündigt. Eveillard verweist auf die semantische Verwechslung zwischen Test-first und TDD als grundlegenden Fehler in DHHs Argumentation. ### Der angemessene Anwendungsbereich von TDD > "TDD eignet sich besonders gut für Domain-Code, den funktionalen Kern eines Bounded Context. Den Kern des Hexagons, den Kern des Reaktors. Eine Berechnungs-Engine, feingranulare Geschäftsregeln, überall Grenzfälle. Dort weiß ich nicht, wie ich es anders machen sollte als mit TDD. Aber letztlich macht das nur einen kleinen Teil der Codebasis aus, höchstens 30 %." | Code | TDD relevant? | |------|----------------| | Domain / Geschäftsregeln / Berechnungs-Engine | EINDEUTIG JA | | Glue-Code / Orchestrierung / IO | Weniger | | UI / Framework-Boilerplate | Nicht erforderlich | | Eveillards Schätzung | max. 30 % der Codebasis | ### Verbindung zum Veille-Corpus #### Relevanz für den KI- / Coding-Agenten-Corpus 2025–2026 Der Artikel stammt aus dem Jahr 2022 (also vor der Explosion der Coding-Agenten), resoniert aber mit aktuellen Debatten:
14. Kent Beck — Vibe Coding vs TDD. (2024-10-17): Beck stellt fest, dass Vibe Coding und TDD sich nicht gegenseitig ausschließen — TDD bleibt für Domain-Code relevant, genau Eveillards Position.
15. Beck — Augmented Coding Beyond Vibes. (2025-06-25): die "augmented coding"-Haltung stützt sich auf Guardrails (Tests), die TDD von Natur aus liefert.
16. Frizzo. Year With Claude Code (2026-05-05): "writing muscle atrophy" — eine TDD-Praxis aufrechtzuerhalten ist genau ein Gegenmittel gegen die Atrophie der manuellen Praxis.
17. Osmani Cognitive Surrender. (2026-05-05): "PRs ~100 lines max", Solo-Keyboard-Zeit — konvergiert mit Eveillards Idee, dass TDD den Entwickler innerhalb der methodischen Praxis des Handwerks hält.
18. Lattice. (2026-05-05): Atoms / Molecules / Refiners — feine Granularität, genau das, was TDD fördert. #### Konvergenz "Werkzeug, keine Religion"
19. Eveillard. "TDD ist keine Religion, sondern ein Werkzeug."
20. Karpathy. (2026-04-29): "jagged intelligence" — ein Werkzeug mit Wirksamkeitsgrenzen.
21. DORA ROI 2026. (2026-04-21): "all models are wrong but useful" — methodische Demut.
22. Talisman Ontology Pipeline Refresh. (2026-05-04): "the work cannot be skipped" — Methodik als Disziplinierungswerkzeug.
23. → Ethische Konvergenz: Ablehnung sowohl des Dogmatismus ALS AUCH der Ablehnung eines methodischen Werkzeugs. #### Konvergenz "begrenzter Anwendungsbereich"
24. Eveillard. TDD = max. 30 % der Codebasis (Domain-Code).
25. Stanford. (zitiert von DORA): 35–40 % Produktivität Greenfield vs. ≤10 % Brownfield — ungleiche Verteilung je nach Kontext.
26. Ng The Batch #350. (2026-04-24): Frontend > Backend > Infra > Research — kontextabhängige Beschleunigung.
27. → Konvergenz: kein methodisches Werkzeug ist universell anwendbar — der relevante Anwendungsbereich muss stets bewertet werden. ### Zu markierende Einschränkungen
28. Artikel streng genommen außerhalb des KI-Corpus. — Fokus auf Craft / historisches TDD. Nur indirekt relevant.
29. Keine empirischen Zahlen. — konzeptionelle Argumentation, keine Studie.
30. Keine Auseinandersetzung mit Coding-Agenten. in der Version von 2025 (die Aktualisierung vom März 2025 scheint die KI-/Agenten-Debatte nicht aufgegriffen zu haben).
31. Der Anwendungsbereich von 30 % ist eine Schätzung, die von Eveillard nicht belegt wird — je nach Kontext diskutabel (ein Compiler könnte zu 80 % Domain sein).
32. Stark auf FP/Hexagonal ausgerichteter Rahmen. — kann für Entwickler, die stark in OOP/Rails verwurzelt sind, dogmatisch wirken.
33. Geht nicht ein. auf die Debatte über die Auswirkung von CI/CD auf die Teststrategie, die andere Autoren (insbesondere DORA) als entscheidend erachten. ### Zu verwenden für
34. Interne Craft-/TDD-Schulungen. französischsprachiges Referenzlehrmaterial.
35. Team-Debatten zu TDD. strukturierte Argumentation zur Klärung von Test-first vs. TDD.
36. Verknüpfung mit dem Coding-Agenten-Corpus 2026. Einordnung aktueller Debatten (vibe coding, Agenten, KI-augmentiert) in die historische Kontinuität der Craft-Debatten.
37. Quellenmaterial. der Aphorismus "TDD ist keine Religion, sondern ein Werkzeug" — eine verwendbare, prägnante Formel.