Der Flaschenhals in der Softwareentwicklung war nie das Programmieren, sondern das Verstehen des Problems. Über den unterschätzten ROI von Verständnis.
Zu “test driven development” hat John Ousterhout einiges geschrieben in “A Philosophy of Software Design”.
tl;dr: “test driven development” ist kacke.
Ousterhout nennt das “debugging a system into existence”. Man erstellt erst ohne durchgängiges Konzept code mit beliebig vielen Fehlern. Dann testet man ein bisschen und beseitigt die Fehler, auf die man trifft. Fälle, die man nicht testet, werden logischerweise wahrscheinlich wieder in Fehler laufen. Weil dem Code kein solides Konzept zugrunde liegt. Weitere Änderungen macht man dann so, dass wieder mit minimalen Änderungen - kein Design, kein grundsätzliches Refactoring - die gewünschte Funktionalität zu sehen ist.
Und den Code durch ausgiebiges Testen und korrigieren einigermaßen Fehlerfrei zu machen, dauert länger als ihn gleich richtig zu designen.
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…
Cool. Ich habe selbst festgestellt, dass ich mit TDD den Code mehr rate als darüber nachzudenken. Schön zu wissen, dass ich nicht der einzige bin, der so fühlt.
So wie ich test driven development erlebt habe ging es darum die Tests vor der Implementation zu entwickeln - das hatte nichts mit unsolidem Konzept zu tun. Das war bei Programmierern eher ungeliebt weil das Gegenteil erforderlich war: Sie muessten sich darueber Gedanken machen wie der Code aussehen soll bevor sie den taetsaechlichen Code schreiben um dafuer sinnvolle Tests zu bauen. Das wurde oft als “das sollten doch Architekten machen” gesehen, “ich leg einfach los und das wird dann irgendwann”.
Zu “test driven development” hat John Ousterhout einiges geschrieben in “A Philosophy of Software Design”.
tl;dr: “test driven development” ist kacke.
Ousterhout nennt das “debugging a system into existence”. Man erstellt erst ohne durchgängiges Konzept code mit beliebig vielen Fehlern. Dann testet man ein bisschen und beseitigt die Fehler, auf die man trifft. Fälle, die man nicht testet, werden logischerweise wahrscheinlich wieder in Fehler laufen. Weil dem Code kein solides Konzept zugrunde liegt. Weitere Änderungen macht man dann so, dass wieder mit minimalen Änderungen - kein Design, kein grundsätzliches Refactoring - die gewünschte Funktionalität zu sehen ist.
Und den Code durch ausgiebiges Testen und korrigieren einigermaßen Fehlerfrei zu machen, dauert länger als ihn gleich richtig zu designen.
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…
Cool. Ich habe selbst festgestellt, dass ich mit TDD den Code mehr rate als darüber nachzudenken. Schön zu wissen, dass ich nicht der einzige bin, der so fühlt.
Ousterhouts Buch ist wirklich super empfehlenswert, es ist nicht so dick!
So wie ich test driven development erlebt habe ging es darum die Tests vor der Implementation zu entwickeln - das hatte nichts mit unsolidem Konzept zu tun. Das war bei Programmierern eher ungeliebt weil das Gegenteil erforderlich war: Sie muessten sich darueber Gedanken machen wie der Code aussehen soll bevor sie den taetsaechlichen Code schreiben um dafuer sinnvolle Tests zu bauen. Das wurde oft als “das sollten doch Architekten machen” gesehen, “ich leg einfach los und das wird dann irgendwann”.