this post was submitted on 22 Feb 2026
78 points (100.0% liked)
DACH - Deutschsprachige Community für Deutschland, Österreich, Schweiz
5676 readers
398 users here now
Das Sammelbecken auf feddit.org für alle Deutschsprechenden aus Deutschland, Österreich, Schweiz, Liechtenstein, Luxemburg und die zwei Belgier. Außerdem natürlich alle anderen deutschprechenden Länderteile der Welt.
Für länderspezifische Themen könnt ihr euch in folgenden Communities austauschen:
___
Zusätzliche Regeln aus „Lessons learned":
- Postet hier zu allen Themen, die euch interessieren (soweit sie den anderen Regeln genügen)
- Posts oder Antworten, die einen Archive[.]today (oder eines der Derivate) beinhaltet, werden kommentarlos gelöscht
- Es werden Posts zum Thema Nahost / Palästina/Israel hier auf Dach gelöscht.
- Dasselbe gilt für Wahlumfragen, à la Sonntagsumfrage und Wahlergebnisse und Diskussionen darüber. Dafür geibt es !wahl
- Bitte Titel von Posts nur sinnerweiternd und nicht sinnentstellend verändern. Eigene Meinungen gehören in den Superkommentar oder noch besser in einen eigenen Kommentar darunter.
- Neu: Wenn es sich erkennbar um Clickbait handelt, kann man in einfachen Fällen die Antwort in geschweiften Klammern in die Titelzeile packen. Wenn die Antwort komplexer ist, nur den alternativen Titel in geschweiften Klammern in die Titelzeile schreiben und den Originaltitel als Zitat in den Superkommentar.
- Youtube Videos bitte nicht ohne eine zusätzliche Zusammenfassung posten
___
Einsteigertipps für Neue gibt es hier.
___
Eine ausführliche Sidebar mit den Serverregeln usw. findet ihr auf der Startseite von feddit.org
___
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Das entspricht so gar nicht meiner Vorstellung von TDD. Für mich ist TDD, dass man sich explizit vorher Gedanken macht und diese in einer Spezifikation niederschreibt. Die Spezifikation wird dabei in Form von Unit- und Integrationstests verfasst, damit automatisch geprüft werden kann, dass der Code der Spezifikation entspricht.
Echtes TTD, so wie ich es gelernt habe, erfordert, dass du immer nur die kleinstmögliche Änderung an den Unit-Tests machst. Der erste Test prüft z.B. nur, ob es eine Funktion gibt. Dann schreibst du den Code, der genau diese Anforderung umsetzt, also eine Methode, die nichts macht.
Danach fügst du die nächste kleine Anforderung zum Test hinzu und programmierst dann genau die.
Vielleicht gibt’s TTD in verschiedenen Geschmacksrichtungen. Dein Ansatz umgeht zumindest den Nachteil, dass durch das inkrementelle Hinzufügen winziger Funktionen kein „im Großen und Ganzen“ sauberes Modul dabei herausfällt.
Joa, habe TDD nie als Dogma gelernt, sondern aus der Praxis, also kann gut sein, dass das was ich kenne ein pragmatischerer Ansatz ist.
Für mich war immer der relevante Aspekt, dass man eben nicht einfach drauf loscodet, sondern sich vorher Gedanken macht, was die Anforderungen sind, was wiederum eine Grundvoraussetzung für sinnvolles Design ist, daher hat mich eure Beschwerde gerade etwas überrascht...
Das ist genauso, wie Robert "Bob" Martin das beschreibt, und worauf sich die Kritik von John Ousterhout ganz explizit bezieht.
Es gibt dann noch eine Beschreibung von Martin Fowler, dass in einem dritten Schritt im Anschluss daran, dass man den Test mit dem neuen Feature zum funktionieren gebracht hat, man Refactoring macht, bei dem man die Struktur des Codes wieder verbessert und etwas aufräumt.
Das ist natürlich besser als nichts! Aber Ousterhout argumentiert, dass sowohl die initiale Struktur des Codes, als auch spätere Änderungen des Codes vorab geplant und bedacht werden müssen, damit die Codebasis langfristig ihre Konsistenz behält. Viele ungerichtete, nicht geplante Änderungen an einer Codebasis führen halt früher oder später zu einem unrettbaren Durcheinander. Genauso wie es bei einer Bibliothek nicht fubktioniert, wenn man Bücher die zurück gegeben werden, einfach irgendwo in ein Regal stellt wo grad Platz ist - sie sind dann nicht mehr zu finden.
Und genau das, die Struktur des Code und seine Invarianten verstehen und diesen so ändern, dass diese implizite Struktur erhalten bleibt, kann die KI halt nicht, auch nicht bei einer mittelkleinen Codebasis. Die Struktur geht dann verloren, auch wenn die Tests vielleicht noch funktionieren.
Und das Problem ist gerade, dass funktionierende Tests eben nicht eine konsistente interne Struktur des Codes sicherstellen. Das können sie halt gar nicht.