Was, nicht wie
Kurz gesagt: Ein Szenario sagt, was das System tut, nicht wie man über den Bildschirm klickt. „Klicke auf den Button Bestellen“ bricht bei jeder Änderung des Designs, obwohl die Regel dieselbe bleibt. Ein Szenario prüft ein Verhalten: ein „Wenn“. Die Wörter sind die des Fachbereichs: Warenkorb, Bestellung, Lieferung, nicht Tabellen und URLs.
Problem
Vierzig Szenarien und ein Button
Der Shop ändert das Design des Warenkorbs. Der Button „Bestellen“ wird zu „Zur Zahlung“ und wandert in eine neue Zeile. An den Regeln hat sich nichts geändert.
Am nächsten Morgen fallen 40 Szenarien durch. Alle betreffen die Lieferung, und alle beginnen so:
# language: deFunktionalität: Kostenlose Lieferung
Szenario: Lieferung unter der Grenze Angenommen ich öffne die Website des Shops Und ich lege eine Tasse für 49,99 € in den Warenkorb Und ich öffne den Warenkorb Wenn ich auf den Button „Bestellen“ klicke Dann steht am unteren Bildschirmrand „Lieferung: 4,90 €“Auch der Inhaber kann sie nicht lesen. Er sucht die Regel zur Lieferung und sieht Buttons.
Die Idee
Was, nicht wie
Dieses Szenario sagt, wie man über den Bildschirm klickt. Deshalb heißt es imperativ: eine Folge von Befehlen. Dasselbe Beispiel, erzählt als was das System tut, ist deklarativ:
# language: deFunktionalität: Kostenlose Lieferung
Szenario: Eine Bestellung knapp unter der Grenze Angenommen ein Warenkorb von 49,99 € Wenn ich bestelle Dann beträgt die Lieferung 4,90 €Drei Zeilen statt fünf, und keine weiß etwas von Buttons. Wird morgen per Sprache oder über die Mobil-App bestellt, bleibt das Szenario gleich. Die Regel hat sich nicht geändert, also soll sich das Szenario auch nicht ändern.
Das „Wie“ verschwindet nicht. Es zieht in den Code um, der den Schritt „Wenn ich bestelle“ mit dem System verbindet. Dort wird eine Zeile für den neuen Button korrigiert, nicht 40 Szenarien.
Probier es aus
Was oder wie?
Übung
Schreib es um
1. Ohne die Buttons. Der Editor enthält das Szenario vom Anfang der Lektion.
Schreibe das Szenario in der Sprache des Wörterbuchs um: ohne Website, Buttons oder Bildschirm. Füge auch ein Beispiel genau auf der Grenze hinzu, damit beide Fehler abgefangen werden.
Lösung
# language: de
Funktionalität: Kostenlose Lieferung
Szenario: Eine Bestellung knapp unter der Grenze
Angenommen ein Warenkorb von 49,99 €
Wenn ich bestelle
Dann beträgt die Lieferung 4,90 €
Szenario: Eine Bestellung genau auf der Grenze
Angenommen ein Warenkorb von 50,00 €
Wenn ich bestelle
Dann ist die Lieferung kostenlos
Die Schritte zu Buttons und Bildschirmen stehen nicht im Wörterbuch, also können sie nicht laufen. Das Wörterbuch ist die Sprache, die der Fachbereich und das Team teilen: Warenkorb, Bestellung, Lieferung. Jedes der beiden Szenarien fängt einen Fehler ab: die Grenze bei 50,00 € und die Gebühr bei 49,99 €.
Die Idee
Ein Verhalten pro Szenario
Hier ist etwas anderes, das sparsam aussieht:
# language: deFunktionalität: Kostenlose Lieferung
Szenario: Lieferung Angenommen ein Warenkorb von 49,99 € Wenn ich bestelle Dann beträgt die Lieferung 4,90 € Angenommen ein Warenkorb von 50,00 € Wenn ich bestelle Dann ist die Lieferung kostenlosDas sind zwei Szenarien in einem. Fällt es durch, musst du die Zeilen lesen, um herauszufinden, welches Verhalten kaputt ist. Und fällt die erste Hälfte durch, läuft die zweite gar nicht erst.
Die Regel lautet ein Verhalten pro Szenario: ein „Wenn“, und der Name nennt dieses Verhalten. Brauchst du ein „und“ im Namen („Stornieren und Erstatten“), sind es zwei Verhalten.
Übung
Teile es
2. Zwei in einem. In dieser Aufgabe sind zwei „Wenn“-Schritte in einem Szenario ein Fehler.
Teile das Szenario in zwei: jedes mit einem Verhalten und einem Namen, der es nennt.
Lösung
# language: de
Funktionalität: Kostenlose Lieferung
Szenario: Unter 50 € kostet die Lieferung
Angenommen ein Warenkorb von 49,99 €
Wenn ich bestelle
Dann beträgt die Lieferung 4,90 €
Szenario: Ab 50 € ist die Lieferung kostenlos
Angenommen ein Warenkorb von 50,00 €
Wenn ich bestelle
Dann ist die Lieferung kostenlos
Jetzt hat jedes Szenario einen Namen, der sich wie eine Regel liest: „Unter 50 € kostet die Lieferung“, „Ab 50 € ist die Lieferung kostenlos“. Fällt eines durch, sagt der Name, was kaputt ist, ohne dass man die Schritte lesen muss.
Die Idee
Die Sprache des Fachbereichs
Die Wörter in einem Szenario sind die Wörter des Inhabers und des Kunden: Warenkorb, Bestellung, Lieferung, Gutscheincode. Dieselben wie in der Story und auf der Tafel des Example Mapping. Sagt der Fachbereich „Bestellung“, sagt das Szenario nicht „Anfrage“, und der Code sagt nicht cart_submission.
Wir schreiben nicht:
- Namen von Tabellen und Feldern (
orders.delivery_fee); - URLs und Antworten des Servers (
POST /api/orders,200); - Funktionsnamen (
calcDelivery(4999)).
Das sind Entscheidungen des Teams, und sie ändern sich, während die Regel bleibt. Ein Szenario, das sie enthält, bricht ihretwegen, und wer die Regel kennt, kann es nicht lesen.
Genauer, für Neugierige
Die Dokumentation von Cucumber („Writing better Gherkin“) sagt dasselbe: Ein Szenario beschreibt das Verhalten des Systems, nicht wie es gebaut ist, also was, nicht wie. Sie verbietet den imperativen Stil nicht: In manchen Zusammenhängen zählen die Einzelheiten, aber solche Szenarien kosten mehr Pflege.
Wann ist das „Wie“ die Anforderung selbst? Wenn du die Barrierefreiheit des Zahlungsformulars prüfst, sind die Tastatur und die Beschriftungen das Verhalten. Dann sagt das Szenario sie. Aber die Regel zur Lieferung hängt nicht von einem Button ab.
Der Gedanke einer gemeinsamen Sprache für den Fachbereich und das Team hat im Softwareentwurf einen Namen: die allgegenwärtige Sprache (ubiquitous language) aus dem Domain-Driven Design von Eric Evans (2003). Die Wörter im Gespräch, im Szenario und im Code sind dieselben.
Test