Ist BDD für mittlere bis große Projekte skalierbar?

22

In jeder Website, die Sie über BDD (Behaviour Driven Development) lesen, finden Sie ein sehr einfaches, schönes Beispiel, das Ihnen zeigt, wie offensichtlich und einfach es ist, Ihre Anforderungen zu definieren. Der Versuch, diesen Prozess in einem großen Produkt (kein Taschenrechner-Beispiel) zu implementieren, hat mir gezeigt, dass die Dinge ziemlich komplex und unlesbar werden können (oder werden). vor allem Änderungswünsche zu einem späteren Zeitpunkt bedeuten einen hohen Aufwand, um die Integrationstests hierfür zu korrigieren.

Ich frage mich also, ob BDD das wirklich wert ist. Löst es ein Problem, das andere Techniken nicht lösen?

DD
quelle
Schade, ich denke, dieses Problem ist ziemlich konstruktiv, wenn man bedenkt, dass BDD in letzter Zeit immer beliebter wird.
DD
1
Wenn jemand mit genügend Vertretern eine Wiedereröffnung vorschlagen kann, wären das großartige Leute.
DD
Ich würde wieder öffnen, aber Sie haben bereits die erste Antwort akzeptiert ...
MattDavey
1
Ich habe zugesagt, weil es geschlossen war, also wusste ich, dass keine weiteren Antworten möglich waren, aber ich bin wirklich an weiteren Erfahrungsberichten darüber interessiert, ich werde es vorerst nicht akzeptieren
DD
2
ok super :) ich denke auch du solltest die frage ein wenig bearbeiten. Ich denke, Ihre Frage betrifft die Skalierbarkeit von BDD in großen Projekten. "Ist BDD wirklich so gut?" Ist subjektiv. "Skaliert BDD gut für große Projekte?" Ist etwas objektiver.
MattDavey

Antworten:

6

Ich denke, eine der besten Quellen für BDD ist das Specification by Example- Buch. Hier erfahren Sie viel darüber, wie BDD-Tests organisiert werden und wie sie geschrieben werden sollten, damit sie bei Änderungen der Anforderungen nicht zu überarbeitet werden.

Wenn die Dinge in Ihren Tests komplex oder zu kompliziert werden, machen Sie wahrscheinlich etwas falsch. Das gleiche gilt für BDD und TDD. Gute Tests zu schreiben ist schwer und es dauert Monate, um es zu lernen.

Piotr Perak
quelle
3
TDD ist nicht dasselbe. Das Testen einer vordefinierten Einheit kann niemals so komplex werden, es sei denn, Sie haben zu große Einheiten, die nach Code riechen, aber Integrationstests sollen die Interaktion zwischen mehr als einer Einheit, einer Gesamtfunktionalität, testen, wodurch die Komplexität zunimmt linear zu den Anforderungen, dennoch können Sie es nicht in kleinere Stücke brechen, da es nicht mehr Inegtrationstest sein würde, wenn Sie getan werden.
DD
Sie könnten einige komplizierte BDD-Tests anhängen und ich könnte sehen, was getan werden kann, um sie einfacher zu machen.
Piotr Perak
Es ist nicht so einfach, diejenigen, die ich hier habe, sind nicht in Englisch, ich müsste sie übersetzen, wenn ich eine Anforderung finde, die ich leicht in Englisch übersetzen kann, kann ich sie anhängen, aber der Code dahinter ist auch ein Problem, das sein würde zu groß, um hier in einem Beitrag zu befestigen.
DD
Warum wurde das abgelehnt? Ich gab großartige Ressourcen, die OP helfen werden, seine Probleme zu lösen.
Piotr Perak
Das war nicht ich, ich werde +1 geben, um das zu kompensieren, aber ich kann dies nur in 14 Stunden tun, da ich alle meine 30 Stimmen für heute verwendet habe.
DD
5

Es könnte hilfreich sein zu erkennen, dass der BDD-Fokus auf den Gesprächen liegt . BDD ist wirklich ein Analysewerkzeug, das zufällig einige Regressionstests als gutes Nebenprodukt liefert.

Ich habe im Gespräch Szenarien auf allen Ebenen verwendet. Von der Identifizierung verschiedener Stakeholder, um zu sehen, ob eine Veröffentlichung wahrscheinlich gut ankommt, bis hin zur Festlegung des Verhaltens eines Moduls oder einer Klasse .

Es gibt ein paar Tipps und Tricks, die ich vorschlagen kann, um dies zu vereinfachen.

Wenn Sie es noch nie getan haben, wird es sich ändern.

Alles, was für die Domäne oder das Geschäft neu ist, wird sich wahrscheinlich ändern. Möglicherweise stellen Sie fest, dass Sie sich in diesem Bereich befinden, wenn Sie die Szenarien durchgehen, sie in Frage stellen und das Unternehmen sagt: "Oh, ich bin nicht sicher." Dies ist ein gutes Zeichen, um nicht mehr versuchen zu müssen, BDD zu betreiben, sondern um schnelleres Feedback zu erhalten, damit das Unternehmen herausfinden kann, was es will. Sobald sich die Ideen stabilisiert haben, können im Nachhinein Szenarien geschrieben werden.

Alle Projekte haben einen Aspekt, der neu ist, sonst würdest du das nicht tun.

Wenn Sie es schon einmal gemacht haben, ist es langweilig.

Neben neuen, differenzierenden Aspekten weisen Projekte in der Regel auch einige kommodifizierte Aspekte auf, die denen ähneln, die bereits durchgeführt wurden. Wenn ich zum Beispiel ein neues Mobiltelefon produzierte, musste es immer noch telefonieren. "Tätigen Sie einen Anruf" ist ein so bekanntes Szenario, dass wir nicht darüber sprechen müssten. Ebenso sind Dinge wie "Login" oder auch "Benutzerregistrierung" langweilig.

Verwenden Sie für diese nach Möglichkeit Bibliotheken, und Sie müssen dann keine Szenarien um sie herum schreiben. Außerdem tun die anderen Bits zuerst - haben ein bereits angemeldeten Benutzer und herausfinden, was er die Protokollierung in für . Es ist unwahrscheinlich, dass sich diese Bereiche ändern. Daher können Sie möglicherweise ohnehin manuelle Tests durchführen.

Wenn es schon einmal jemand gemacht hat, kann es hilfreich sein, Szenarien durchzusprechen.

Es gibt eine gewisse Differenz zwischen domänenspezifischen Anforderungen, Informationen, die von jemandem relativ gut verstanden werden , und der tatsächlichen Unsicherheit, die sich eher auf den Umfang als auf das tatsächliche Verhalten des Systems bezieht.

Das Durchsprechen von Szenarien kann dem Entwicklerteam helfen, Verhalten zu erkennen, das Wissen eines Experten zu nutzen und sicherzustellen, dass das bekannte, wertvolle Verhalten erfasst wird.

Dies ist der Punkt, an dem BDD am besten funktioniert. Mein Tipp ist, die interessantesten Szenarien oben in der Feature-Datei (oder im Wiki, wenn Sie nicht automatisieren) zu schreiben und alle Szenarien zu löschen, die dupliziert oder als Ergebnis leicht abzuleiten sind.

Verwenden Sie die Szenarien nach Möglichkeit nur als Beispiele für die Funktionsweise der Anwendung . Wenn Sie beispielsweise zeigen möchten, wie die Validierung funktioniert, zeigen Sie einige Beispiele, wie die Anwendung dem Benutzer hilft, ein Formular auszufüllen. Überprüfen Sie mithilfe von Komponententests, dass die Validierung streng ist. Dies ist viel einfacher zu warten und schneller auszuführen.

Weitere Lektüre

Wenn Sie daran interessiert sind, hier sind einige Dinge, die ich geschrieben habe, die helfen könnten.

BDD im Großen

Cynefin für Entwickler , das diese drei Bereiche ausführlicher behandelt

Meine Tutorial-Folien , die alle nett und mit Anmerkungen versehen sind, decken auch den gesamten Stapel ab.

Lunivore
quelle
Vielen Dank für diese informative Antwort. Bitte lesen Sie die angehängten Links
DD
3

Wir haben im letzten Herbst ein ziemlich komplexes ( Domain-Komplexitäts- ) Projekt erstellt, und ich kann ehrlich sagen, dass das Projekt gerettet wurde, indem die Vorarbeiten in BDD übernommen wurden. Ich habe eine starke Korrelation zwischen der Domänenkomplexität und den Vorteilen von BDD gesehen.

Lassen Sie mich eines aus dem Weg räumen: Das Testen komplexer Geschäftsregeln ist schwierig. Die Frage ist, ob Sie versuchen möchten, sich bei jeder Änderung an alle verrückten Szenarien zu erinnern, oder ob Sie über dieses Sicherheitsnetz informiert werden möchten, wenn Sie die Spezifikation gebrochen haben. Nehmen Sie sich die Zeit, um alle Szenarien zu erarbeiten, sie aufzuschreiben und schließlich alle Tests für sie zu schreiben.

Und wenn Sie später wiederkommen und versuchen, einen Sinn für die Dinge zu finden, ist es lebensrettend, diese testbare Spezifikation zu haben.

Adrian Schneider
quelle
1

BDD ist ein auf TDD (Test Driven Development) basierender Entwicklungsprozess. Hier sind einige meiner persönlichen Vor- und Nachteile von TDD:

  • TDD stellt sicher, dass Ihr Bereich gut definiert ist. Auf diese Weise entwerfen Sie zuerst Ihre Testfälle. Stellen Sie dabei eine Erwartung für den Code ein, den Sie schreiben sollen.
  • Mit TDD können Sie Ihren Code schützen. Angenommen, Sie schreiben eine einfache Funktion und fügen später in derselben Funktion einige komplexe Schaltbedingungen hinzu. Wenn jemand anderes diese Funktion ändern möchte, kann er sich morgen auf den Testfall beziehen. Wenn er Ihre Funktion ändern möchte, muss er (meistens) auch den Testfall ändern. Dadurch kann er / sie verstehen, dass hinter dem, was Sie geschrieben haben, eine Begründung steckt.
  • TDD ermöglicht eine schnellere Softwareentwicklung. Jeder von uns hätte dieses Problem beim Codieren angegangen. Wir beginnen mit einer Idee. Und langsam den Überblick verlieren. Am Ende setzen wir unerwünschte Codeteile ein, um einige Szenarien zu bewältigen. In TDD legen Sie die Erwartungen im Voraus fest. Dadurch hindern Sie sich daran, zu weit vom Ziel wegzuwandern.
  • Mit TDD können Sie mögliche Fehler erkennen, bevor das Projekt online geht. Dies hat vor allem mit der Qualität der geschriebenen Testfälle zu tun.

Nachteile:

  • TDD kann anfangs etwas knifflig sein. Viele Menschen verstehen das Konzept eines Testfalls, der die Entwicklung vorantreibt, nicht.
  • TDD kann manchmal zu einem enormen Wartungsaufwand führen. Dies hat mit unerwünschten oder sinnlosen Testfällen zu tun.
  • TDD muss mit einer Prise Salz eingenommen werden. Kein Entwickler verbringt gerne Zeit mit einem Testfall, der von jemand anderem geschrieben wurde. Das Entschlüsseln der Bedeutung des Testfalls kann manchmal zu starken Kopfschmerzen führen.

Ich arbeite an einem Projekt mit mehr als 900.000 Codezeilen. Und ich verfolge immer noch BDD. Eine wichtige Sache, die Sie berücksichtigen müssen, ist die Anzahl der möglichen Fehler, die Sie möglicherweise nur aufgrund der Testfälle abfangen. Ein paar Jahre später werden Sie bei BDD schwören!

Ricketyship
quelle
2
Sie sollten näher auf die Unterschiede zwischen BDD und TDD eingehen und darauf, woher der DDD-Teil stammt.
Benjamin Gruenbaum
1
@BenjaminGruenbaum Im Idealfall gibt es keinen Unterschied zwischen BDD und TDD. BDD, wenn es richtig befolgt wird, ist dasselbe wie TDD! Ich habe also keinen Grund gesehen, den Unterschied als Teil der Antwort einzubringen. Vielen Dank für den Vorschlag!
Ricketyship
1
"TDD ermöglicht eine schnellere Softwareentwicklung." Gab es Studien, die dies bestätigten? Nur neugierig. Ich würde auch erwähnen, dass die Beschleunigung nicht linear ist.
Den
2
@ AlexandreMartins Hah, absolut! Es ist viel wichtiger zu erkennen, dass Sie möglicherweise schlechte Qualitätstests und -szenarien haben, als vorzutäuschen, dass sie alle gute IMO sind.
Lunivore
2
@Lunivore Ja, das ist es, was mich bei BDD / TDD stört. Die Testfälle müssen stark sein. Leider gibt es diese Ansicht in der Entwicklergemeinschaft, dass es in Ordnung ist, solange es Testfälle gibt! Ich habe einmal einen Testfall gesehen, in dem eine Zeile mit einer SQL-Anweisung in eine Tabelle eingefügt und im nächsten Schritt bestätigt wurde! Versuchte der Entwickler, die Funktionalität von Oracle zu testen ?!
Ricketyship