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).