Continuous Delivery als nicht verhandelbare Grundlage KI-gestützter Softwareentwicklung — Dave Farley argumentiert auf seinem Kanal *Modern Software Engineering*, dass KI ohne CD kein Beschleuniger, sondern eine Falle ist (Theory of Constraints und Jevons-Paradoxon angewandt auf generierten Code, ATDD/BDD als Absicherung, Deployment-Pipeline als Qualitätsschiedsrichter).
#Continuous Delivery#Generative KI im SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)
**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.
#Mathieu Eveillard#TDD#Test-Driven Development
**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"*).