BDD - TDD auf BDD-Weise

In TDD ist der Begriff „Abnahmetests“ irreführend. Abnahmetests repräsentieren tatsächlich das erwartete Verhalten des Systems. In agilen Praktiken wird die Zusammenarbeit des gesamten Teams und die Interaktion mit dem Kunden und anderen Stakeholdern betont. Dies hat dazu geführt, dass Begriffe verwendet werden müssen, die für alle Projektbeteiligten leicht verständlich sind.

TDD lässt Sie über das Erforderliche nachdenken Behavior und daher ist der Begriff "Verhalten" nützlicher als der Begriff ‘Test’. BDD ist Test Driven Development mit einem Vokabular, das sich auf Verhalten und nicht auf Tests konzentriert.

Mit den Worten von Dan North: „Ich fand die Verlagerung vom Denken in Tests zum Denken in Verhalten so tiefgreifend, dass ich anfing, TDD als BDD oder Behaviour Driven Development zu bezeichnen.“ TDD konzentriert sich darauf, wie etwas funktionieren wird, BDD konzentriert sich darauf, warum wir es überhaupt bauen.

BDD beantwortet die folgenden Fragen, mit denen Entwickler häufig konfrontiert sind:

Frage Antworten
Wo soll man anfangen? Außenseite nach innen
Was zu testen? Benutzergeschichten
Was nicht testen? noch etwas

Diese Antworten ergeben den folgenden Story-Framework:

Story Framework

Als ein [Role]

Ich will [Feature]

damit [Benefit]

Dies bedeutet: 'Wenn a Feature ausgeführt wird, ergibt sich das Ergebnis Benefit ist für die Person, die das spielt Role.'

BDD beantwortet die folgenden Fragen weiter:

Frage Antworten
Wie viel auf einmal testen? sehr wenig konzentriert
Wie sollen ihre Tests genannt werden? Satzvorlage
Wie man versteht, warum ein Test fehlschlägt Dokumentation

Diese Antworten ergeben das Beispiel-Framework wie folgt:

Example Framework

Given ein anfänglicher Kontext,

When ein Ereignis tritt ein,

Then einige Ergebnisse sicherstellen.

Dies bedeutet: „Beginnend mit dem anfänglichen Kontext, wenn ein bestimmtes Ereignis eintritt, wissen wir, was die Ergebnisse sind should be. '

Das Beispiel zeigt also das erwartete Verhalten des Systems. Die Beispiele werden verwendet, um verschiedene Szenarien des Systems zu veranschaulichen.

Geschichte und Szenarien

Betrachten wir die folgende Abbildung von Dan North zu einem Geldautomaten.

Geschichte

As a Kunde,

I want Bargeld an einem Geldautomaten abzuheben,

so that Ich muss nicht in der Bank Schlange stehen.

Szenarien

Für diese Geschichte gibt es zwei mögliche Szenarien.

Scenario 1 - Konto ist gutgeschrieben

Given Das Konto ist gutgeschrieben

And Die Karte ist gültig

And Der Spender enthält Bargeld

When Der Kunde verlangt Bargeld

Then Stellen Sie sicher, dass das Konto belastet wird

And Stellen Sie sicher, dass Bargeld ausgegeben wird

And Stellen Sie sicher, dass die Karte zurückgegeben wird

Scenario 2 - Das Konto ist über das Überziehungslimit hinaus überzogen

Given Das Konto ist überzogen

And Die Karte ist gültig

When Der Kunde verlangt Bargeld

Then Stellen Sie sicher, dass eine Ablehnungsmeldung angezeigt wird

And Stellen Sie sicher, dass kein Bargeld ausgegeben wird

And Stellen Sie sicher, dass die Karte zurückgegeben wird

Das Ereignis ist in beiden Szenarien gleich, aber der Kontext ist unterschiedlich. Daher sind die Ergebnisse unterschiedlich.

Entwicklungszyklus

Der Entwicklungszyklus für BDD ist ein outside-in Ansatz.

Step 1- Schreiben Sie ein Beispiel für einen Geschäftswert auf hoher Ebene (außerhalb) (mit Gurke oder RSpec / Capybara), der rot wird. (RSpec erstellt ein BDD-Framework in der Ruby-Sprache)

Step 2 - Schreiben Sie ein untergeordnetes (internes) RSpec-Beispiel für den ersten Implementierungsschritt, der rot wird.

Step 3 - Implementieren Sie den Mindestcode, um dieses Beispiel auf niedrigerer Ebene zu übergeben. Sehen Sie, wie er grün wird.

Step 4 - Schreiben Sie das nächste RSpec-Beispiel auf niedrigerer Ebene, um Schritt 1 zu bestehen, der rot wird.

Step 5 - Wiederholen Sie die Schritte 3 und 4, bis das übergeordnete Beispiel in Schritt 1 grün wird.

Note - Die folgenden Punkte sollten beachtet werden:

  • Red/green state ist ein Berechtigungsstatus.

  • Wenn Ihre Tests auf niedriger Ebene grün sind, haben Sie die Berechtigung, neue Beispiele zu schreiben oder vorhandene Implementierungen umzugestalten. Sie dürfen im Rahmen des Refactorings keine neuen Funktionen / Flexibilität hinzufügen.

  • Wenn Ihre Tests auf niedriger Ebene rot sind, haben Sie die Berechtigung, Implementierungscode nur zu schreiben oder zu ändern, damit die vorhandenen Tests grün werden. Sie müssen dem Drang widerstehen, den Code zu schreiben, um Ihren nächsten Test zu bestehen, der nicht vorhanden ist, oder Funktionen zu implementieren, die Sie für gut halten (der Kunde hätte nicht gefragt).