Beziehung zwischen BDD und TDD

Wie ist das Verhältnis von BDD und TDD?

Nach meinem Verständnis fügt BDD zwei wichtige Dinge zu TDD hinzu: Benennungstests (Sicherstellen / Sollte) und Abnahmetests. Soll ich TDD während der Entwicklung von BDD folgen? Wenn ja, sollten meine TDD-Komponententests im selben Stil angegeben werden?

BDD fügt einen Zyklus um den TDD-Zyklus hinzu.

Sie beginnen also mit einem Verhalten und lassen das Ihre Tests vorantreiben, dann lassen Sie die Tests die Entwicklung vorantreiben. Im Idealfall wird BDD durch eine Art Abnahmetest gesteuert, dies ist jedoch nicht zu 100% erforderlich. Solange Sie das erwartete Verhalten definiert haben, sind Sie in Ordnung.

Angenommen, Sie schreiben eine Anmeldeseite.

Beginnen Sie mit dem glücklichen Weg:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Diese Gegeben-Und-Wenn-Und-Dann-Und-Syntax ist in der verhaltensgetriebenen Entwicklung weit verbreitet. Einer der Vorteile ist, dass es von Nicht-Entwicklern gelesen (und mit Schulung geschrieben) werden kann. Das heißt, Ihre Stakeholder können die Liste der Verhaltensweisen anzeigen, die Sie für den erfolgreichen Abschluss einer Aufgabe definiert haben, und prüfen, ob dies der Fall ist entspricht ihren Erwartungen lange bevor Sie ein unvollständiges Produkt veröffentlichen.

Es gibt eine Skriptsprache namens "Gherkin", die der oben genannten sehr ähnlich ist und es Ihnen ermöglicht, Testcode hinter die Klauseln in diesen Verhaltensweisen zu schreiben. Sie sollten nach einem Gherkin-basierten Übersetzer für Ihr übliches Entwicklungsframework suchen. Das liegt außerhalb des Rahmens dieser Antwort.

Wie auch immer, zurück zum Verhalten. Ihre aktuelle Anwendung tut dies noch nicht (wenn ja, warum fordert jemand eine Änderung an?), Sodass Sie diesen Test nicht bestehen, unabhängig davon, ob Sie einen Testläufer verwenden oder einfach manuell testen.

Jetzt ist es an der Zeit, zum TDD-Zyklus zu wechseln, um diese Funktionalität bereitzustellen.

Unabhängig davon, ob Sie BDD schreiben oder nicht, sollten Ihre Tests eine gemeinsame Syntax haben. Eine der häufigsten ist die von Ihnen beschriebene "sollte" -Syntax.

Schreiben Sie einen Test: ShouldAcceptValidDetails. Durchlaufe den Rot-Grün-Refaktor-Zyklus, bis du damit zufrieden bist. Bestehen wir jetzt den Verhaltenstest? Wenn nicht, schreiben Sie einen weiteren Test: ShouldRedirectToUserDefaultPage. Rot-Grün-Refaktor bis du glücklich bist. Waschen, spülen, wiederholen, bis Sie die im Verhalten festgelegten Kriterien erfüllen.

Und dann gehen wir zum nächsten Verhalten über.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Jetzt hättest du dies nicht vorwegnehmen sollen, um dein früheres Verhalten zu übertreffen. Sie sollten diesen Test an dieser Stelle nicht bestehen. Kehren Sie also zu Ihrem TDD-Zyklus zurück.

Und so weiter, bis Sie Ihre Seite haben.

Wir empfehlen das Rspec Book, um mehr über BDD und TDD zu erfahren, auch wenn Sie kein Ruby-Entwickler sind.

Mein Verständnis davon:

• BDD begann mit einer Umbenennung von TDD, um den Fokus auf das Verhalten deutlicher zu machen.
• Es bietet mehr formale Unterstützung (DSL und Tools), um sich auf das Verhalten und die ausführbaren Spezifikationen zu konzentrieren.
• BDD kann nun als Obermenge von TDD angesehen werden. Es ist im Laufe der Zeit gewachsen, mehr von der Anforderungserhebungsseite der Dinge zu erfassen, aber dennoch ist die Seite des Entwicklungsprozesses ein zentraler Bestandteil davon.

Also, um den TDD zu adressieren, erledigt der BDD den richtigen Teil. BDD begann mit einem Sprachwechsel von TDD, um die Absicht des Prozesses klar zu machen. Der Einführungsartikel von Dan North über BDD erklärt, warum es sinnvoll ist, sich auf das Wort Verhalten zu konzentrieren und nicht auf Test. Es hilft zu bestätigen, dass Sie nicht nur die richtige Software erstellen, sondern auch die richtige Software. Dies war immer Teil eines guten TDD-Ansatzes, aber Dan hat es ein wenig in BDD kodiert.

Was BDD meiner Meinung nach etwas expliziter macht als TDD oder zumindest formalisiert und Toolunterstützung bietet, ist dieser Zwei-Zyklus- / Doppelschleifen- / Zoom-in-Zoom-out- / Outside-in-Ansatz. Sie beschreiben zunächst das erwartete Verhalten des Features (der äußeren Schleife) und zoomen dann in die innere Schleife hinein, um sich mit den Spezifikationen auf niedriger Ebene zu befassen.

Von http://www.metesreau.com/ncraft-workshop/

Gherkin bietet in Verbindung mit Tools wie Cucumber und SpecFlow die Möglichkeit, diese übergeordneten Feature-Spezifikationen zu schreiben und sie dann mit Code zu verknüpfen, der den Anwendungscode ausführt. Ich würde argumentieren, dass sich BDD hier möglicherweise anders anfühlt als TDD, aber es tut immer noch dasselbe, nur mit etwas zusätzlicher Tool-Unterstützung und DSL. Etwas näher an der traditionellen TDD sind Tools wie rspec, nspec und spock. Diese ähneln ein bisschen mehr dem Vorgang, den Sie bei „herkömmlicher“ TDD ausführen würden, jedoch mit einer stärker verhaltensorientierten Sprache.

In BDD in Action von John Ferguson Smart (sehr empfehlenswert) plädiert er für einen Double-Loop-Ansatz, der mit jBehave auf der äußeren Ebene der ausführbaren Spezifikationen beginnt und sich dann in ein Tool wie Spock für die Low-Level-Spezifikationen verlagert.

BDD bringt das Konzept des Test-Driven den Geschäftsinteressenten näher. Gherkin ist so konzipiert, dass es für Unternehmen lesbar ist. Bei der Idee einer lebendigen Dokumentation, dh automatisch erstellten Fortschrittsberichten aus Ihren ausführbaren Spezifikationen, geht es darum, den Stakeholdern Feedback zu geben.

Ein weiterer Teil von BDD, in dem TDD als Teil eines größeren Prozesses tatsächlich zum Bestandteil von BDD wird, sind die Anforderungen. Ideen wie Feature Injection, Impact Mapping und Real Options sind Teil dieser Seite.

Für die kanonische Antwort darauf ist es vielleicht am besten, noch einmal zu Dan North zu gehen . Wenn Ihr Team ausschließlich aus Entwicklern besteht, ist BDD = TDD. Wenn Ihr Team eine ganze Reihe von Interessengruppen einbezieht, ist BDD näher an XP, wobei TDD ein Teil davon ist.

Wie ist das Verhältnis von BDD und TDD?

Sie sind das gleiche.

Soweit ich weiß, fügt BDD zwei wichtige Dinge über TDD hinzu: Benennung von Tests (sicherstellen / sollten)

Das ist nicht wirklich etwas, was BDD "hinzufügt". Es ist nur eine andere Konvention, die es einfacher machen soll, TDD zu lehren und zu verstehen.

Die Leute, die BDD erstellt haben, unterrichteten alle TDD und sie stellten fest, dass das Schwierigste zu verstehen war, dass TDD absolut nichts mit Testen zu tun hat. Sobald die Schüler diese Hürde überwunden hatten, fiel es ihnen viel leichter. Aber es ist sehr schwer , sich vom Denken über das Testen zu trennen , wenn das Wort "Test" (oder eine verwandte Terminologie wie "Behauptung") praktisch überall vorkommt . Also wechselten sie ein paar Wörter.

Aber es sind nur die Worte! Es gibt keinen tatsächlichen Unterschied zwischen TDD und BDD.

und Abnahmetests.

Akzeptanztests sind für TDD genauso wichtig wie für BDD. Wieder: Es gibt keinen Unterschied zwischen TDD und BDD: TDD richtig gemacht ist BDD, BDD ist TDD richtig gemacht.