# eveillard-tdd-is-dead-long-live-testing-reponse-dhh-2022-12-07

## Veille

**Mathieu Eveillard** veröffentlicht am **7. Dezember 2022** (letzte Aktualisierung 17. März 2025) auf seinem persönlichen Blog eine **punktweise Gegenargumentation** zum berühmten Essay von **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Der Artikel ist in die Kategorien **Craft / Best-of** eingeordnet, eine Haltung des **Software-Craftsman**, der **Test-Driven Development** undogmatisch verteidigt. **Zentrale Unterscheidung**, die DHH laut Eveillard entgeht: ***"Test-first"*** (alle Tests vor jeglichem Code schreiben) vs. ***"Test-Driven Development"*** (Tests **leiten** mich beim Schreiben von Code an, sodass ich jedes Mal ein Stück Code *"als Reaktion"* auf einen neuen Test schreibe). DHH kritisiert tatsächlich *Test-first*, nennt es jedoch TDD — eine Verwechslung, die **eine völlig andere Art zu programmieren verdeckt**. **Punktweise Erwiderungen**: (1) *"TDD als Hammer, um Ungläubige niederzuschlagen"* — Eveillard räumt den deontologischen Punkt ein, definiert aber *"guten Code"* neu: nicht nur die Abwesenheit von Bugs, sondern **feingranulare Unit-Tests**, die das Verhalten auf niedrigster Ebene dokumentieren, direkt beim Code angesiedelt, ein **Sicherheitsnetz**; (2) *"Verschiebung vom Unit- zum System-Test"* — TDD **sagt nichts** über System-Tests aus und **behauptet nicht**, dass es außerhalb von TDD nichts gebe; System-Tests **ersetzen** Unit-Tests **nicht** (eine Ende-zu-Ende getestete Steuererklärung ergibt keinen Sinn); **Testpyramide** — jeder Typ trägt seinen Anteil bei, Unit-Tests für Feedback im **Millisekundenbereich** + frühe Fehlererkennung; (3) *"Horrende Architektur-Monstrositäten (Service Objects, Command Patterns)"* — Eveillard entgegnet, dass er **diese Effekte in der funktionalen Programmierung nicht beobachtet**, sodass der Effekt wahrscheinlich auf **OOP** zurückzuführen ist, nicht auf TDD; räumt aber ein, dass übermäßige Dependency Injection Test und Implementierung koppeln kann. **Ausgewogenes Fazit**: *"TDD ist keine Religion, sondern ein Werkzeug"*. TDD eignet sich besonders gut für **Domain-Code** (den funktionalen Kern eines *Bounded Context*, den *Kern des Hexagons*) — Berechnungs-Engines, feingranulare Geschäftsregeln, jede Menge Grenzfälle — ***"höchstens 30 % der Codebasis"***. Erwähnt das **Gesetz des Instruments** (wenn das Werkzeug nicht hilft, liegt es daran, dass man ihm verfallen ist). **Relevanz für den Corpus**: ein **Craft-Artikel außerhalb des KI-Corpus**, aber archivierungswürdig, um aktuelle Debatten über Coding-Agenten (Becks *Augmented Coding Beyond Vibes*, 2025-06-25, Vibe Coding vs. TDD, Frizzos *writing muscle atrophy*) in die historische Traditionslinie der Craft-Debatten rund um TDD einzuordnen. Zu verwenden als **Grundlagenmaterial** für Schulungen.

## Titre Article

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

## Date

2022-12-07

## URL

https://www.mathieueveillard.com/blog/tdd-is-dead-long-live-testing

## Keywords

Mathieu Eveillard, TDD, Test-Driven Development, DHH-Gegenargumentation, David Heinemeier Hansson, TDD is dead long live testing 2014, Unterscheidung Test-first vs. Test-Driven Development, feingranulare Unit-Tests, Sicherheitsnetz, Testpyramide, Feedback im Millisekundenbereich, frühe Fehlererkennung, funktionale Programmierung, Dependency Injection, Kopplung von Test und Implementierung, Domain-Code, Bounded Context, Kern des Hexagons, Hammer, um Ungläubige niederzuschlagen, Verschiebung vom Unit- zum System-Test, horrende Architektur-Monstrositäten, Service Objects Command Patterns, Religion vs. Werkzeug, Gesetz des Instruments, 30 Prozent Codebasis, Glenn Gould Pianist, Craft, Best-of, Software Craftsmanship, Mathieu-Eveillard-Blog, 7. Dezember 2022, Aktualisierung 17. März 2025, Verbindung zu den Coding-Agenten-Debatten 2025-2026, Kent Beck Augmented Coding Beyond Vibes

## Authors

**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD, du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).

## Ton

**Profil**: Individueller Craft-Blogartikel, ausführliches, maßvolles polemisches Essayformat, Ton eines **bescheidenen, aber standhaften Software-Craftsman**. Zielpublikum: Entwickler von Mittelstufe bis Senior, Tech Leads, Craft-Trainer, DHH-/Rails-Leser, die neugierig auf die andere Seite der Argumentation sind. Sekundärpublikum: Führungskräfte, die interne Team-Debatten zu TDD verstehen möchten.

**Stil**: Ich-Perspektive auf Französisch, **höflich-konversationelles Register** (*"Ich bezweifle, dass der Herr eine Antwort von mir erwartet"*), gegliedert in **3 Abschnitte**, die den 3 ausgewählten DHH-Zitaten entsprechen. Keine Ad-hominem-Angriffe: Eveillard erkennt DHH als *"vielschichtige Persönlichkeit"* an (Schöpfer von Ruby on Rails + Sieger der 24 Stunden von Le Mans), lobt dessen *"ikonoklastische"* Ideen, widerlegt aber entschieden die Schlussfolgerungen. **Punktweise Argumentation** in der großen rhetorischen Tradition. Sorgfältig ausgearbeitete Metaphern (Glenn Gould als nicht-akademischer Pianist, der *Kern des Hexagons*, der *Kern des Reaktors*).

**Zentrale Aphorismen**:
- ***"TDD ist keine Religion, sondern ein Werkzeug."*** (das zentrale Fazit).
- ***"Man sollte bedenken, dass ich mich irren könnte und dass das, was für mich gut ist, nicht unbedingt für jemand anderen gut ist."*** (die Demut des Craftsman).
- ***"Je früher ein Bug entdeckt wird, desto geringer sind die Kosten."*** (die ökonomische Rechtfertigung von TDD).
- ***"Letztlich macht das nur einen kleinen Teil der Codebasis aus, höchstens 30 %."*** (der angemessene Anwendungsbereich von TDD).

**Ausgearbeitete Metaphern**:
- ***Sicherheitsnetz*** — Tests als Netz, das vor Regressionen schützt.
- ***Testpyramide*** — jeder Testtyp trägt seinen Anteil zur Struktur bei (Referenz auf Mike Cohn).
- ***Kern des Hexagons / Kern des Reaktors*** — Referenz auf die **hexagonale Architektur** (Alistair Cockburn) — der funktionale Kern eines Bounded Context.
- ***Glenn Gould, nicht-akademischer Pianist*** — künstlerische Analogie: ein großer Interpret kann akademische Konventionen verlassen und trotzdem ein meisterhaftes Ergebnis erzielen. Erlaubt es Eveillard, DHH zuzugestehen, dass **vor allem das Ergebnis zählt**.
- ***Gesetz des Instruments*** — wenn das Werkzeug nicht hilft, liegt es daran, dass man in die Maslow-Falle getappt ist (*"wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus"*).

**Epistemische Haltung**: **ausgewogen und selbstkritisch**. Eveillard:
1. Räumt DHH Punkte ein (Ethik, kein Fingerzeigen, das Ergebnis zählt).
2. **Klärt die Verwechslung** zwischen Test-first und TDD auf.
3. Begrenzt **den Anwendungsbereich von TDD auf 30 % der Codebasis** (Domain-Code).
4. Lehnt gleichzeitig **TDD-Dogmatismus** und die **Ablehnung von TDD** ab.

**Autorität**: aufgebaut durch (a) **technische Präzision** (Test-first/TDD, Hexagonal, Bounded Context, FP-Unterscheidungen), (b) **rhetorische Stringenz** — punktweise, ohne Strohmann-Argumente, (c) **explizite Demut** (*"ich könnte mich irren"*), (d) **interne Blog-Referenzen** (strategisches vs. taktisches DDD, DevOps-Missverständnis), die ein kohärentes Gesamtwerk zeigen. Einschränkung: **individuelle Blog-Autorität** ohne institutionelle oder empirische Validierung.

## Pense-betes

- **Datum / Quelle**: **7. Dezember 2022** (ursprünglich), **17. März 2025** (letzte Aktualisierung). Persönlicher Blog **mathieueveillard.com**. Kategorien: `craft`, `best-of`.
- **Autor**: **Mathieu Eveillard** — Entwickler / Craft-Coach / Trainer.
- **Zielscheibe**: DHH, *"TDD is dead. Long live testing."* (RailsConf 2014, Signal v Noise-Beitrag).
- **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**:
- Über die reine Abwesenheit von Bugs hinaus;
- **Unit-Tests**, die das Verhalten auf niedrigster Ebene dokumentieren;
- **Direkt beim Code angesiedelt** (co-located);
- **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**:
- TDD **verbietet nichts**, was über Unit-Tests hinausgeht.
- System-Tests **ersetzen** Unit-Tests **nicht** (eine Ende-zu-Ende getestete Steuererklärung = absurd).
- **Testpyramide** — jeder Typ trägt seinen eigenen Wert bei:
- Unit-Tests = Feedback im **Millisekundenbereich** → leitet das Schreiben von Code via TDD an;
- 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:
- **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.
- **Beck — Augmented Coding Beyond Vibes** (2025-06-25): die *"augmented coding"*-Haltung stützt sich auf **Guardrails** (Tests), die TDD von Natur aus liefert.
- **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.
- **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.
- **Lattice** (2026-05-05): Atoms / Molecules / Refiners — feine Granularität, genau das, was TDD fördert. #### Konvergenz "Werkzeug, keine Religion"
- **Eveillard**: *"TDD ist keine Religion, sondern ein Werkzeug."*
- **Karpathy** (2026-04-29): *"jagged intelligence"* — ein Werkzeug mit Wirksamkeitsgrenzen.
- **DORA ROI 2026** (2026-04-21): *"all models are wrong but useful"* — methodische Demut.
- **Talisman Ontology Pipeline Refresh** (2026-05-04): *"the work cannot be skipped"* — Methodik als Disziplinierungswerkzeug.
- → **Ethische Konvergenz**: Ablehnung sowohl des **Dogmatismus** ALS AUCH der **Ablehnung** eines methodischen Werkzeugs. #### Konvergenz "begrenzter Anwendungsbereich"
- **Eveillard**: TDD = max. 30 % der Codebasis (Domain-Code).
- **Stanford** (zitiert von DORA): 35–40 % Produktivität Greenfield vs. ≤10 % Brownfield — **ungleiche Verteilung je nach Kontext**.
- **Ng The Batch #350** (2026-04-24): Frontend > Backend > Infra > Research — **kontextabhängige Beschleunigung**.
- → **Konvergenz**: **kein methodisches Werkzeug ist universell anwendbar** — der **relevante Anwendungsbereich** muss stets bewertet werden. ### Zu markierende Einschränkungen
- **Artikel streng genommen außerhalb des KI-Corpus** — Fokus auf Craft / historisches TDD. Nur indirekt relevant.
- **Keine empirischen Zahlen** — konzeptionelle Argumentation, keine Studie.
- **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).
- 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).
- **Stark auf FP/Hexagonal ausgerichteter Rahmen** — kann für Entwickler, die stark in OOP/Rails verwurzelt sind, dogmatisch wirken.
- **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
- **Interne Craft-/TDD-Schulungen**: französischsprachiges Referenzlehrmaterial.
- **Team-Debatten zu TDD**: strukturierte Argumentation zur Klärung von *Test-first vs. TDD*.
- **Verknüpfung mit dem Coding-Agenten-Corpus 2026**: Einordnung aktueller Debatten (vibe coding, Agenten, KI-augmentiert) in die **historische Kontinuität** der Craft-Debatten.
- **Quellenmaterial**: der Aphorismus *"TDD ist keine Religion, sondern ein Werkzeug"* — eine verwendbare, prägnante Formel.

## RésuméDe400mots

**Mathieu Eveillard** veröffentlicht am **7. Dezember 2022** (letzte Aktualisierung 17. März 2025) auf seinem persönlichen Blog eine **punktweise Gegenargumentation** zum berühmten Essay von **David Heinemeier Hansson** (DHH) *"TDD is dead. Long live testing."* (2014). Artikel kategorisiert als `craft / best-of`.

**Zentrale Unterscheidung**, die DHH laut Eveillard entgeht: ***Test-first*** (alle Tests vor jeglichem Code schreiben) vs. ***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). DHH kritisiert tatsächlich **Test-first**, nennt es jedoch TDD — eine Verwechslung, die *"eine völlig andere Art zu programmieren verdeckt"*.

**Drei Erwiderungen**: (1) *TDD als Hammer, um Ungläubige niederzuschlagen* — Eveillard räumt den deontologischen Punkt ein, definiert aber *"guten Code"* neu als feingranulare, direkt beim Code angesiedelte Unit-Tests, ein Sicherheitsnetz; (2) *Verschiebung vom Unit- zum System-Test* — TDD **sagt nichts** über System-Tests aus und **behauptet nicht**, dass es außerhalb von TDD nichts gebe; System-Tests **ersetzen** Unit-Tests **nicht** (eine Ende-zu-Ende getestete Steuererklärung = absurd); **Testpyramide** — Unit-Tests für Feedback im Millisekundenbereich + frühe Fehlererkennung; (3) *Horrende Architektur-Monstrositäten (Service Objects, Command Patterns)* — Eveillard beobachtet diese Effekte nicht in der **funktionalen Programmierung**, sodass sie eher der OOP zuzuschreiben sind, nicht TDD.

**Ausgewogenes Fazit**: ***"TDD ist keine Religion, sondern ein Werkzeug."*** TDD eignet sich besonders gut für **Domain-Code** (den funktionalen Kern eines *Bounded Context*, den *Kern des Hexagons*) — Berechnungs-Engines, feingranulare Geschäftsregeln, jede Menge Grenzfälle — also ***"höchstens 30 % der Codebasis"***. Erwähnt das **Gesetz des Instruments** (wenn das Werkzeug nicht hilft, liegt es daran, dass man in die Hammerfalle getappt ist).

**Relevanz für den KI-Veille-Corpus**: ein **Craft-Artikel**, der streng genommen außerhalb des KI-Corpus liegt, aber Resonanz zeigt mit **Kent Beck** (Vibe Coding vs TDD 2024-10 + Augmented Coding 2025-06), **Frizzos** *writing muscle atrophy*, **Osmanis** *Cognitive Surrender* (PRs auf 100 Zeilen begrenzt + Solo-Keyboard-Zeit), **Lattice** (feine Granularität Atoms/Molecules). **Ethische Konvergenz** zu *"Werkzeug, keine Religion"* mit **Karpathy** (jagged intelligence), **DORA** (*"all models are wrong but useful"*), **Talisman** (*"the work cannot be skipped"*). **Konvergenz beim begrenzten Anwendungsbereich** mit **Stanfords 35–40 % Greenfield vs. ≤10 % Brownfield** und **Ngs** *Frontend > Backend > Infra > Research*.

Zu verwenden für interne Craft-Schulungen, Team-Debatten zu TDD, Verknüpfung mit dem Coding-Agenten-Corpus 2026, als Quelle für einen prägnanten Aphorismus.

## GrapheDeConnaissance

- Mathieu Eveillard —publie→ TDD is dead. Long live testing. (réponse à DHH) (DOCUMENT, 0.97)
- Mathieu Eveillard —s_oppose_à→ David Heinemeier Hansson (DHH) (PERSONNE, 0.96)
- David Heinemeier Hansson (DHH) —publie→ TDD is dead. Long live testing. (article original, 2014) (DOCUMENT, 0.97)
- Test-first —est_variante_de→ Test-Driven Development (METHODOLOGIE, 0.96)
- Mathieu Eveillard —affirme_que→ DHH critique Test-first en l'appelant TDD (AFFIRMATION, 0.95)
- Mathieu Eveillard —affirme_que→ le TDD n'est pas une religion, c'est un outil (AFFIRMATION, 0.96)
- Test-Driven Development —s_applique_à→ Code domaine / bounded context / cœur hexagone (CONCEPT, 0.94)
- Mathieu Eveillard —affirme_que→ le code domaine TDD-pertinent représente 30% de la codebase au plus (AFFIRMATION, 0.91)
- Tests unitaires —permet→ feedback millisecondes + détection bug précoce (CONCEPT, 0.95)
- Mathieu Eveillard —affirme_que→ les tests système ne remplacent pas les tests unitaires (AFFIRMATION, 0.95)
- Tests unitaires + intégration + acceptance + e2e —fait_partie_de→ Pyramide de tests (CONCEPT, 0.94)
- Programmation fonctionnelle —réduit→ service objects + command patterns monstrosities (CONCEPT, 0.91)
- Trop d'injection de dépendances —permet→ couplage test implémentation (CONCEPT, 0.93)
- Loi de l'Instrument —s_applique_à→ TDD utilisé inappropriément (CONCEPT, 0.92)
- Bilan Eveillard —converge_avec→ Beck Vibe Coding vs TDD, Beck Augmented Coding, Frizzo writing muscle, Osmani Cognitive Surrender (CONCEPT, 0.9)
- Position outil_pas_religion —converge_avec→ Karpathy jagged intelligence, DORA all models wrong, Talisman work cannot be skipped (CONCEPT, 0.89)

---
Canonical: https://www.thekb.eu/de/fiches/eveillard-tdd-is-dead-long-live-testing-reponse-dhh-2022-12-07/