Argumente für und gegen TDD/BDD

[ctwx]

Hallo liebe Community,

ein Kollege möchte gerne in Zukunft TDD in unseren Projekten nutzen und meine Erfahrung mit TDD als auch mit BDD sind, dass es mehr Schall und Rauch ist, als alles andere. Es wird gerne davon gesprochen, den Zyklus einzuhalten und immer (fast wie fanatische Christen – auf Moslems herumhacken macht kein Spaß ) zuerst Tests schreiben, im Endeffekt häufig doch einfach nur drauf losprogrammiert wird.

Die Idee ist generell gar nicht so schlecht, aber bei der Umsetzung scheint es, wie ich das sehe, eher zu scheitern. Da ich nun nicht der erfahrenste Entwickler bin, wollte ich mal nach eurer Meinung zu TDD, BDD und traditionellen Softwareentwicklung fragen. Was habt ihr da für Meinungen zu? Was Pro- und Kontra-Agumente könntet ihr mir nennen?

Ich habe in Bezug auf BDD bisher mit Rails gearbeitet und auch das "RSpec Book" durch.

Vielen Dank! Ich freue mich auf eure Meinungen.

[Colttt]

Nur mal so für mich als ahnungsloser? Was isn TDD/BDD??

[ctwx]

Nur mal so für mich als ahnungsloser? Was isn TDD/BDD??

TDD steht für Test Driven Development und BDD steht für Behavior Driven Development. Beide sehen vor, dass man zuerst Tests schreibt, und dann entsprechend erst die Umsetzung.

Du schreibst einen Test, ob dein Programm Feature X erfüllt. Dann lässt du den Test laufen, um zu schauen, ob der Test syntaktisch korrekt ist. Der sollte natürlich fehlschlagen. Dann programmierst du das Feature und schaust, ob das Feature das erwartete Ergebnis liefert. Wenn nicht, programmierst du weiter, bis der Test läuft. Rot-Grün-Refactor, so nennt sich das meine ich, bei BDD. Diese Grafik zeigt das sehr schön:


Das soll Zeit sparen, weil man gleich korrekten Code schreibt. BDD geht noch einen Schritt weiter als TDD, in dem Verhalten eine Rolle spielt. Dort werden, zum Beispiel bei Rails mit Cucumber Tests in menschenlesbarer Form geschrieben:

Code: Alles auswählen

@javascript
Feature: Change email

  Scenario: Change my email
    Given I am signed in
    When I go to the users edit page
    And I fill in the following:
      | user_email         | new_email@newplac.es           |
    And I press "Change email"
    Then I should see "Email changed"
    And I follow the "confirm_email" link from the last sent email
    Then I should see "activated"
    And my "email" should be "new_email@newplac.es"

Anschließend werden die einezelnen Zeilen in Code umgesetzt. Das Beispiel kommt im übrigen aus den Tests von Diaspora: https://github.com/diaspora/diaspora/bl ... il.feature

[cronoik]

zuerst Tests schreiben, im Endeffekt häufig doch einfach nur drauf losprogrammiert wird.

Das ist aber ein menschliches Problem und kein Problem der Methodik. Entweder man zieht die Sache durch oder man lässt es. Insbesondere bei Projekten welche nicht nur entwickelt, sondern auch gewartet und weiterentwickelt werden (ALM) habe ich gute Erfahrungen mit TDD gemacht. Die entwickelten Tests hatten mMn eine deutlich höhere Qualität welche die Weiterentwicklung vereinfachten, da sie halt nicht nur Beiwerk waren. Je nach Erfahrung der Beteiligten mit TDD, muss jedoch beim ersten Projekt deutlich mehr Zeit eingeplant werden um sich an den Denkansatz gewöhnen zu können. Das Verständnis dafür das dass Zeit braucht, muss aber bei Entwicklern und Management vorhanden sein.

[sebastian_rose]

Ich war nie ein großer TDD-Fan, bin aber zunehmend Freund von möglichst lückenlosen Tests (Code-Coverage).

Das Dogma "Tests FIRST" fühlt sich für mich noch sperrig an. Ich praktiziere mittlerweile eher sowas wie "Tests ASAP", schreibe also möglichst sofort nach dem ersten Entwurf einer Methode die entsprechenden Tests. Das wichtigste ist erstmal möglichst 100%-ige Code-Coverage der Tests. 85% ist das schon eine ganz brauchbare Basis. Messen der Coverage schadet nicht. Und wenn jemand Jenkins aufsetzt, um automatisch nach jedem Commit zu testen, sage ich nicht nein.

Naja, die Vorteile von für jeden Kollegen ohne Akrobatik ausführbaren Tests brauche ich wohl nicht herauszuarbeiten. In meinen Augen ist der wichtigste neben "Sicherheit", meine eigene Entwicklung hin zu bessererer Code-Qualität im Sinne von "lesbar", "modular", "wiederverwendbar", "portabel".

Ich nutze mit ruhigerem Gewissen die Teile von Hausgemachtem Code, die ich testen kann (ohne erst irgendwas frickeln zu müssen). Ungetesteten Code sehe ich zunehmend als Risiko und meide seine Nutzung und sei es auch mein eigener. Spätestens nach 3 Monaten weis ich doch gar nicht mehr, ob das Zeug, was da mal programmiert wurde, überhaupt fertig geworden ist und funktioniert - von fehlerfrei wollen wir mal gar nicht reden.

TDD ist irgendwann einfach der nächste logische Schritt.

[Liffi]

Je schlechter ein Sprache refaktorisierbar ist, desto wichtiger ist TDD und eine ausreichende Test Coverage. An bestehenden Perl oder Javascript Code würde ich mich sonst nicht herantrauen.

Es gab übrigens vor einiger Zeit eine interessante Diskussion zwischen Kent Beck, Martin Fowler und David Heinemeir Hensson ob TDD tot ist[1].
TDD hilft tatsächlich dabei, den Code wirklich schön granular und testbar zu schreiben, zwingt einen aber auch dazu .

[1]Is TDD dead?

[TRex]

TDD sorgt vor allem dafür, dass man testbaren Code schreibt. Spätestens, wenn man merkt, dass die Funktion mit dem dictionary als Argument mit 2^50 möglichen Kombinationen nicht testbar ist, merkt man auch, dass die Funktion zu komplex ist und schreibt sie um - test driven wäre das vorher aufgefallen. Ich selbst schreibe aber auch erst ein paar Zeilen Code, um mir eine ungefähre Struktur zu bauen. Ungeachtet von TDD/BDD gibts nämlich noch auf nem anderen Layer:

Unittests: testet einzelne Funktionen en detail, möglichst alle Fälle abdeckend
Integrationstests: Komponente A funktioniert mit Komponente B (weil bei Unittests äußere Komponenten wegge"mock"t werden und die Schnittstellenintegration nicht getestet wird)
Systemtests: Das vollständige System wird getestet, vorzugsweise mit use-cases von außen.
Akzeptanztests: Systemtests auf Aufgabenniveau, also ob eine bestimmte Umsetzung im Rahmen einer Aufgabe funktioniert, funktioniert auch als technische Demo.

Find ich sehr wichtig, sich diese Konzepte verinnerlicht zu haben.

Übrigens kenne ich ein Team, das regelmäßig alten Javascript-Code refactored, um neuen Ansprüchen gerecht zu werden... geht also

[ctwx]

Je schlechter ein Sprache refaktorisierbar ist, desto wichtiger ist TDD und eine ausreichende Test Coverage. An bestehenden Perl oder Javascript Code würde ich mich sonst nicht herantrauen.

Es gab übrigens vor einiger Zeit eine interessante Diskussion zwischen Kent Beck, Martin Fowler und David Heinemeir Hensson ob TDD tot ist[1].
TDD hilft tatsächlich dabei, den Code wirklich schön granular und testbar zu schreiben, zwingt einen aber auch dazu .

[1]Is TDD dead?

Interessant. Bei Perl kann ich es nachvollziehen, bei JavaScript habe ich das Problem noch nicht gehabt, selbst bei Projekten, die in einem Rails-Projekt schon 200 MB hatten. Danke für den Verweis auf die Diskussion, jedoch werde ich es mir nicht anschauen. David Heinemeir Hensson ist meiner Meinung nach ein Extremist was das Thema angeht. Nach dem was ich so von ihm gesehen habe, ist er ein Mensch der nur schwarz und weiß kennt. (Ich will hier gar nicht weiter ausführen, ich denke, da muss man sich sein eigenes Bild schaffen. )

TDD sorgt vor allem dafür, dass man testbaren Code schreibt. Spätestens, wenn man merkt, dass die Funktion mit dem dictionary als Argument mit 2^50 möglichen Kombinationen nicht testbar ist, merkt man auch, dass die Funktion zu komplex ist und schreibt sie um - test driven wäre das vorher aufgefallen. Ich selbst schreibe aber auch erst ein paar Zeilen Code, um mir eine ungefähre Struktur zu bauen. Ungeachtet von TDD/BDD gibts nämlich noch auf nem anderen Layer:

Unittests: testet einzelne Funktionen en detail, möglichst alle Fälle abdeckend
Integrationstests: Komponente A funktioniert mit Komponente B (weil bei Unittests äußere Komponenten wegge"mock"t werden und die Schnittstellenintegration nicht getestet wird)
Systemtests: Das vollständige System wird getestet, vorzugsweise mit use-cases von außen.
Akzeptanztests: Systemtests auf Aufgabenniveau, also ob eine bestimmte Umsetzung im Rahmen einer Aufgabe funktioniert, funktioniert auch als technische Demo.

Find ich sehr wichtig, sich diese Konzepte verinnerlicht zu haben.

Übrigens kenne ich ein Team, das regelmäßig alten Javascript-Code refactored, um neuen Ansprüchen gerecht zu werden... geht also

Macht durchaus Sinn. Ich denke, ich werde einen Mittelweg gehen, und bei kleineren Sachen definitiv erst später schreiben. Häufig fällt mir auf, dass der erste Entwurf nicht so gut war und ich das wieder verwerfe, weswegen es sich für mich da wohl nicht lohnt, vorher Tests zu schreiben, wenn ich das noch mal neu mache.

Ich danke euch vielmals für eure Antworten. Wenn noch mehr Meinungen zu dem Thema bestehen, bitte auch gerne Gegenmeinungen, dann wäre ich da sehr dankbar für!