Ist BDD ein Ersatz für TDD?

Überhaupt nicht. BDD ist nur eine Variante von TDD.

In TDD formulieren Sie Ihre Anforderungen als ausführbaren Test und schreiben dann den Produktionscode, um den Test zu erfüllen. BDD macht nichts anderes, als diese Anforderungen in eine besser lesbare Form umzuformulieren und macht die Tests für einen menschlichen Leser, der den Testbericht betrachtet, etwas ausführlicher. (Btw: Um dies zu erreichen, benötigt BDD viel mehr Code als traditionelle datengetriebene Komponententests ...)

Das ist alles.

Thomas

Ich habe einen anderen Standpunkt als andere Responder.

Dan North hat BDD mit seiner Beratungsarbeit zu TDD beauftragt, als er sah, dass viele Leute vom "Test" -Teil verwirrt waren, da sie Testerfahrung hatten, entschied er sich, den Namen zu ändern. Also zuerst war BDD genau das, was TDD ist, richtig erklärt. Danach begann Dan, die Idee der Verwendung ausführbarer Spezifikationen (Komponententests) zu erweitern, um die Implementierungen durch Hinzufügen weiterer Spezifikationsebenen zu unterstützen. Er wurde von User Storys inspiriert, so dass Sie mit dem einfachsten von den meisten Tools implementierten BDD Anforderungen als User Story-Szenarien schreiben können, als Sie Code schreiben, der Komponententests generiert, und dann von Unit Tests, die Sie bei der Implementierung verwenden. Sie sehen also im Vergleich zu TDD eine andere Spezifikationsebene - User Stories. Viele Tools beinhalten vorbereitete Übersetzungen von User Storys zu Tests, so viele vergessen sie wie Sie, aber sie sind immer noch da und können nicht vollständig weggelassen werden - praktisch und theoretisch ist das Programmieren von User Stories nicht effizient. Aber das ist nicht der Punkt, Sie verwenden User Stories, um Anforderungen von Stakeholdern zu sammeln und zu beweisen, dass Sie sie implementieren, indem Sie Abnahmetests durchführen.

Es gibt viele andere kleine Dinge in BDD, Sie lesen besser Dans Blog, um sie zu verstehen, aber der Hauptpunkt ist, dass BDD eine Erweiterung von TDD ist, auch außerhalb der Implementierungsphase, so dass sie nicht gegenseitig vertauscht werden können .

Gabriel hat fast recht.

Der grundlegende Unterschied auf Ebene der Einheiten ist, dass BDD das Wort "sollte" anstelle von "testen" verwendet. Es stellt sich heraus, dass, wenn Sie "Test" sagen, die meisten Leute darüber nachdenken, was ihr Code macht und wie er es testen kann. Mit BDD betrachten wir - und hinterfragen, was unser Code tun sollte . Es ist ein subtiler, aber wichtiger Punkt, und wenn Sie wissen wollen, warum das so mächtig ist, lesen Sie weiter über Neuro-Linguistisches Programmieren - insbesondere über die Art und Weise, wie Wörter die Gedanken und das Modell der Welt beeinflussen. Als ein kurzes Beispiel beginnen viele Leute, die neu bei TDD sind, ihren Code zu fixieren, so dass niemand ihn kaputt machen kann. BDDer neigen dazu, Beispiele zu geben, die den Wert ihres Codes demonstrieren, so dass Leute ihren Code sicher ändern können.

Dan bemerkte, während er mit Chris Matts sprach und JHehave schrieb, dass er das auf ein Szenario-Niveau bringen könnte (Szenarien sind nicht ganz dasselbe wie Geschichten). Da wir bereits "sollte" auf einer Einheitsebene verwenden, machte es Sinn, Dinge auf Englisch zu schreiben (ich neige dazu, "sollte mir geben" anstatt "sollte zurückkehren", zum Beispiel). Acceptance Test Driven Development - ATDD - gibt es schon lange, aber das war AFAIK, das erste Mal, als jemand sie in englischer Sprache verfasst hatte, wobei die beteiligten Unternehmen beteiligt waren.

Es ist mehr als nur ein Ersatz für TDD. Es ist eine andere Art, über das Testen nachzudenken - sehr konzentriert auf das Lernen, bewusst Bereiche zu entdecken, in denen wir vielleicht dachten, wir wüssten, was wir taten, aber nicht, um Unwissenheit und Missverständnisse aufzudecken und zu helfen. Es funktioniert auf vielen Ebenen. Das Feature Injection von Chris Matts bringt dies auf die höhere Ebene, bis hin zur Projektvision.

Wir schreiben immer noch Beispiele - oder Spezifikationen, wenn Sie möchten - auch auf einer Einheitsebene, aber wirklich, es ist ein Muster, das viel höher geht als sogar Szenarien. Wenn Sie mehr wissen möchten, finden Sie meinen Blog möglicherweise nützlich , Dan ist noch besser . Auch Chris hat ein Comic über Real Options , das umreißt einige der Muster, die ich erwähnt habe.

Soweit ich verstehe, sind die Vorteile von BDD gegenüber TDD:

• Entkoppeln der Tests von den Implementierungsdetails. Also die Feature-Dateien werden nicht brechen, nur die Schrittdateien, wenn Sie die Implementierung ändern, aber nicht das Verhalten.
• Wiederverwenden von Testcode Sie können das gleiche mit TDD tun, wenn Sie benutzerdefinierte Assertions, Fixtures, Helpers usw. definieren. Aber wir (zumindest ich) kopieren normalerweise den Testcode (schlechte Angewohnheit). Es ist viel einfacher, Code durch BDD wiederzuverwenden. Es wird noch einige Wiederholungen geben, aber zumindest wird es in Gurke sein.

Alles andere geht genauso wie normalerweise von TDD. Sie können also jede Assertion-Lib in den Step-Definitionen verwenden, die Sie in den Unit-Tests verwenden würden. Der einzige Unterschied besteht darin, dass Sie eine weitere Abstraktionsebene hinzugefügt haben, indem Sie in Ihrem Testcode unterscheiden, was (Funktionsbeschreibung in Gurke) und wie (Schrittdefinitionen in einer Programmiersprache).

BDD sollte das Verhalten aus einer Benutzerperspektive heraus betonen und ist ideal geeignet, um End-to-End-Tests durchzuführen, eine Art von DSL für die Akzeptanztest-getriebene Entwicklung. Es kann TDD ergänzen, aber es ist definitiv kein Ersatz. TDD ist genauso eine Design-Aktivität wie eine Test-Aktivität (Code, der schlecht entworfen ist, ist schwer zu testen - Unit-Tests fördern gutes Design). BDD hat nichts mit Design zu tun. Es ist eine Art von Tests, die Abstraktionen weg vom Code insgesamt.

In der Praxis führt BDD unter der Haube zu viel mehr Code als normale Akzeptanztests. Daher bevorzuge ich die Erstellung einer internen DSL in einer normalen Programmiersprache, um meine Akzeptanztests zu steuern. Wie bei Komponententests betont BDD das Verhalten aus der Sicht eines Benutzers und sollte daher nicht auf Einheitenebene verwendet werden.

BDD ist ein Versuch, die Kommunikationslücke zwischen Business-Stakeholdern und Programmierern zu überbrücken. In einigen Bereichen kann es nützlich sein, beispielsweise bei Bankanwendungen, bei denen die Detailgenauigkeit bei Zinsberechnungen wichtig ist, und erfordert einen direkten Input von Domänenexperten. IMHO BDD ist nicht das Allheilmittel, dass einige seiner Akolyten behaupten, es sei und sollte nur verwendet werden, wenn es einen zwingenden Grund dafür gibt.