Zu meinem Verständnis von TDD und BDD

"Will you be my Valentine?" by Felix Francis
gefunden über Photo Suggest

Mein Kollege Stefan Roock schreibt in seinem Blogpost von einem "Vergleich: BDD und TDD":

"Ich [wurde] bereits früh von TDD (Test Driven Development) infiziert. Irgendwann kam eine neue Bewegung auf: BDD (Behaviour Driven Design). Wie viele andere TDDler habe ich lange nicht verstanden, was der Vorteil von BDD sein soll."

Dito. Verstehe den Vorteil von BDD bis heute nicht. Ich präzisiere: Verstehe ich bis heute nicht für mich.

Stefan scheint seinen Frieden mit BDD nun gemacht zu haben, denn er schreibt:

"[Der Vorteil] ist mir inzwischen klar gewor[d]en."

Stefan nimmt in seinem Blogpost eine Portion Ruby-Code eines TDD-Beispiels mit RUNIT her und übersetzt es in ein BDD-Beispiel mit RSpec. Dabei fällt ihm dies auf:

"Strukturell sind Test und BDD-Spezifikation identisch. Die BDD-Spezifikation ist bei den Vergleichen lediglich etwas leichter lesbar.
Der Vergleich termin.bezeichnung.should == "TDD-Dojo" ist der natürlichsprachlichen Formulierung "Die Terminbezeichnung sollte 'TDD-Dojo' sein." ähnlicher als assert_equal("TDD-Dojo", termin.bezeichnung)."

Lange habe ich gegrübelt, was mich hier stört. Und das ist mir inzwischen klar geworden. Was heißt denn leichter lesbar? Was ist natürlichsprachlich?

BDD selbst verweist als eines seiner Vorteile auf die Sapir-Whorf-Hypothese. Diese Hypothese besagt

"... dass die Sprache das Denken formt."

Nach dem, wie und was wir (be-)sprechen, nach dem handeln wir auch. Sprechen wir über Tests, so sichern wir primär Eigenschaften zu. Sprechen wir dagegen von Spezifikationen, so beauftragen wir Eigenschaften und geben an, wie sie sein sollen. Demnach weichen test und assert aus xUnit specification und should aus RSpec. Die Idee ist, dass wenn der Programmierer keine Tests mehr schreibt, sondern Spezifikationen, wenn er keine Zusicherungen über, sondern einen Auftrag (should; soll; Auftrag) an den Code schreibt, dass er dann anders denkt.

Dieses Andersdenken bezieht sich auf das letzte D in TDD: Die einen übersetzen es mit Development, die anderen mit Design. Letzteres ist für viele TDDler die eigentliche Qualität des TDD: Das Design wird getrieben durch die Tests. Es geht nicht um Verifikation, sondern um Spezifikation. Diesen Gedanken greift das BDD nun auf und fragt: Wenn wir spezifizieren statt zu testen, wenn wir schreiben, was der Code tun soll, anstatt etwas zuzusichern, dann sollten wir das auch so aufschreiben, damit wir durch die Worte wohl geleitet handeln.

Mag sein, dass das für jemanden gilt, der neu ist in TDD. Das kann ich mir gut vorstellen. "TDD? Was soll das sein? Ach, Tests? So so, verstehe, geht ums Testen von Software. Alles klar, man her damit!" Und schon ist der Neue mit falschen Annahmen bei der Sache. Nicht gut. Da hilft BDD, oder?

Seit über 8 Jahren programmiere ich testgetrieben, was mich als TDD-Neuling disqualifiziert. Meine Vorstellung von Tests sind stark kontextbehaftet. Geht's um TDD? Dann sind meine Tests keine Verifikationen, sondern meine Mittel fürs Design. Geht's um die Endabnahme, Akzeptanztests, QA? Dann sind meine Tests verifizierend. Da hilft kein BDD, um mein Handeln durch eine andere Terminologie zu besseren Ergebnissen zu leiten.

"BDD"

, frei nach Dave Astels,

"macht man, wenn man TDD richtig macht."

Und bislang war das der Strohhalm, nach dem ich gegriffen habe, wenn ich nicht verstand, warum BDD nun anders sein soll als TDD. Dieser Strohhalmgriff beruht auf meiner Annahme, dass ich bereits korrektes TDD mache. Subjektiv, vielleicht vermessen, möglicherweise anmaßend, auf jedenfall nicht objektiv bewertbar ist die Aussage, ob ich korrektes TDD mache. Das war mir immer ein sehr kleiner Strohhalm.

Wittgenstein ist da schon ein größerer Strohhalm. Von ihm las ich neulich wieder in Prechts "Wer bin ich und wenn ja, wie viele?", und von seiner Idee der Präzisionssprache. Wittgensteins Theorie besagte, dass die Sprache als Abbild der Realität dienen kann. Und er lag falsch, wurde widerlegt:

"[Der Sprache] wichtigste Funktion besteht darin, zu verstehen und verstanden zu werden. Ob etwas verständlich ist oder nicht bestimmen sowohl die Grammatik wie der Kontext. So kann der Satz 'Ich sehe schwarz' meinen, dass ich vor einem schwarzen Bild stehe und seine Farbe beschreibe. Ebenso gut aber kann er bedeuten, dass ich in einer Sache pessimistisch bin. Dem jungen Wittgenstein waren solche Sätze ein Greuel, aber die Sprache wimmelt nur so von Mehrdeutgkeiten. Die schlichte Wahrheit, die jede Idee einer Präzisionssprache zum Scheitern verurteilt, ist, dass die Bedeutung eines Satzes durch den Gebrauch der Wörter geformt wird."

Die Bedeutung wird also durch den Gebrauch der Wörter geformt. Die Wörter selbst formen nicht die Bedeutung. Es ist eine Implikation, keine Äquivalenz. Und ich benutze Worte wie Test und Zusicherung schon seit 8 Jahren. Kein Wunder also, dass die Bedeutung von TDD bei mir entsprechend geformt wurde. Das, was hinter TDD steckt, erschließt sich mir mehr über die Worte Test und Zusicherung, weniger über Spezifikation und Auftrag.

Wenn ich einem xDD-Neuling im TDD-Camp erkläre, dass er die Tests vor dem Code schreiben, dass er Einfachheit anstreben, dass er gnadenlos refaktorisieren, dass er Redundanzen eliminieren und dass er noch ein paar TDD-Gebräuche mehr anwenden soll, und wenn ich dem xDD-Neuling dann sage, dass das Testgetriebene Entwicklung ist, dann habe ich die Bedeutung von Tests im Kontext des TDD durch den Gebrauch der Worte wie Tests und Zusicherungen entsprechend geformt. Aus meiner Sicht heraus sind für einen xDD-Neuling beide Begriffsgruppen, Tests-Zusicherung und Spezifikation-Auftrag, am Anfang seiner Ausbildung gleich bedeutungsleer oder -voll. Das, was diese Wortgruppen mit dem verbindet, was hinter TDD/BDD steckt, dem Treiben des Designs also, wird erst durch den Gebrauch, also durch die Anwendung dieser Wörter geformt. Wenn das stimmt, dann ist es schnurzpiepegal, ob man nun TDD oder BDD macht.

Mein Fazit: Taten mögen den Worten folgen (Sapir-Whorf-Hypothese; BDD), sicherlich wird Bedeutung durch den Gebrauch von Worten erlangt (Widerlegung Wittgensteins; xDD). Egal, ob ich BDD oder TDD anwende, beide benutzen eine jeweils eigene Terminologie, die Bedeutung durch den Gebrauch derselben erlangt. Ergo hat weder BDD noch TDD einen Vorteil gegenüber der jeweils anderen Technik.

Versöhnlich möchte ich schließen. Precht schreibt:

"Und die entscheidende Frage beim Verständnis von Sätzen ist nicht, ob etwas wahr ist oder falsch, sondern ob die Verständigung im beabsichtigten Sinne gelingt oder nicht gelingt."

Verständigung im beabsichtigten Sinne: Egal ob TDD oder BDD, es geht nicht darum, ob Tests oder Spezifikationen, es geht darum, zu verstehen, dass in beiden Fällen Design getrieben wird.

Wir verstehen uns?