Ist BDD ein Ersatz für TDD?

Question

Ich frage mich, ob BDD ein Ersatz von TDD ist? Was ich jetzt verstehe, ist, dass wir in einem ultimativen BDD keine Unit-Tests mehr haben. Stattdessen gibt es Geschichten/Szenarien/Features und "Testschritte". Und es sieht wie ein vollständiger Ersatz von TDD für mich aus. TDD ist tot?

Answer 1

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

In TDD formulieren Sie Ihre Anforderungen als ausführbaren Test, dann schreiben Sie 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 herkömmliche datengetriebene Komponententests ...)

Das ist alles.

Thomas

Answer 2

Ich habe eine andere Sicht auf diese als andere Responder.

Dan North erstellt BDD seine Beratungsarbeit auf TDD, als er sah, dass viele Menschen durch den "Test" Teil verwirrt waren, weil 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 von ausführbaren 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 implementiert haben, indem Sie Abnahmetests durchführen.

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

Answer 3

Gabriel ist fast richtig.

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 realisierte, während er mit Chris Matts sprach und JBehave schrieb, dass er dies auf ein Szenario-Level bringen konnte (Szenarien sind nicht ganz dasselbe wie Geschichten). Weil 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 dies war AFAIK, das erste Mal, als jemand sie in englischer Sprache mit beteiligten Geschäftsinteressenten verfasste.

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. Die Feature Injection von Chris Matts bringt dies in den höherstufigen Bereich, 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 Sie might find my blog useful, Dan's is even better. Auch, Chris has a comic book on Real Options, die einige der Muster skizziert, die ich erwähnt habe.

Answer 4

Bei BDD geht es nicht darum, TDD zu ersetzen. Es geht darum, Ihren TDD-Praktiken mehr Struktur und Entschlüsselung zu geben. Das Schwierigste an TDD ist, dass Entwickler ohne das größere Bild kaum wissen, was getestet und wie viel getestet werden soll. BDD bietet mit dieser Grauzone eine sehr konkrete Richtlinie. Überprüfen Sie diesen Beitrag heraus,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 5

Soweit ich die Vorteile von BDD über TDD verstehen sind:

• Entkoppelung die Tests von den Implementierungsdetails. So werden die Feature-Dateien nicht unterbrochen, nur die Schrittdateien, wenn Sie die Implementierung ändern, aber nicht das Verhalten.
• Wiederverwenden bestehender 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 das Element (Funktionsbeschreibung in Gurke) von der Definition (Schrittdefinitionen in einer Programmiersprache) in Ihrem Testcode trennen.

Answer 6

Sie können den Begriff "Specification by Example" für BDD verwenden, die einen wichtigen Aspekt dieser Methode betonen: Zusammenarbeit spezifizieren - durch Workshops, Besprechungen oder Telefonkonferenzen. In diesen Sitzungen mit verschiedenen Interessengruppen werden konkrete Beispiele zur Veranschaulichung von Anforderungen verwendet. Die Erörterung von Anforderungen in Form von Beispielen hilft dabei, ein gemeinsames Verständnis der Problemdomäne und möglicher Lösungen zu schaffen.

Per Zufall sind Spezifikationen mit Beispielen gut für die Testautomatisierung geeignet. Als Ergebnis verbessern Sie normalerweise die Testabdeckung. Aber diese Methode hilft auch involve non-technical stakeholders. Die Tools, die Ihnen helfen create business readable input sind von Natur aus nicht mit Programmiersprachen verwandt, basieren aber oft auf simple document formats, die von vielen Leuten leicht verständlich sind.

Answer 7

BDD sollte das Verhalten aus der Sicht eines Benutzers betonen und eignet sich ideal für End-to-End-Tests, 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 vom Code insgesamt abstrahiert.

In der Praxis führt BDD unter der Haube zu viel mehr Code als normale Akzeptanztests, daher bevorzuge ich das Erstellen einer internen DSL in einer normalen Programmiersprache, um meine Akzeptanztests zu fahren. 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 Geschäftspartnern 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.