Bessere User Stories mit Gherkin und Cucumber schreiben

Automatisierte Unit-Tests für die Software zu schreiben, die wir entwickeln, kann wie eine große Menge an Vorarbeit ohne einen klaren Nutzen erscheinen. Der langfristige Nutzen für die Gesundheit, Zufriedenheit und Geschwindigkeit Ihres Teams übersteigt jedoch die anfängliche Investition. Neben vielen anderen Vorteilen fangen automatisierte Tests Fehler ab, ermöglichen ein kontinuierliches Deployment und erleichtern den Entwicklern die Arbeit an unbekanntem Code.

Cucumber ist ein Werkzeug, mit dem wir automatisierte Softwaretests auf eine einfach zu schreibende und leicht zu lesende Weise erstellen können. Obwohl sich viele Produktteams schwer tun, automatisierte Tests auf die Beine zu stellen (weil sie vielleicht noch nie von Tools wie Cucumber gehört haben), haben sich fast alle unwissentlich mit einer seiner Schlüsselkomponenten beschäftigt – Gherkin.

Wenn es mit Bedacht eingesetzt wird, ist das Schreiben von Akzeptanzkriterien in Gherkin-Form eine großartige Möglichkeit für Teams, zu definieren und zu vereinbaren, was „fertig“ für die Features bedeutet, die sie bauen. Trotz seiner Einfachheit, ist Gherkin eine sehr nuancierte Sprache. Mit dieser Nuancierung kommt eine Menge Verwirrung darüber, was eine gut geschriebene Anweisung von einer schlecht geschriebenen unterscheidet, besonders für Leute, die neu in Gherkin sind.

Isoliert betrachtet können die Eigenheiten von Gherkin verwirrend erscheinen, aber wenn man sie im Kontext von automatisierten Cucumber-Tests betrachtet, machen diese Feinheiten viel mehr Sinn. Dieser Artikel geht darauf ein, wie Gherkin und Cucumber zusammenpassen, so dass Sie sehen können, wie Sie Gherkin heute effektiver einsetzen können. Am Ende dieses Artikels werden Sie erfahren, wie eine vollständige Gherkin + Cucumber-Implementierung funktioniert und wie der Aufbau einer Bibliothek von gut geschriebenen Gherkin-Szenarien den Weg für automatisierte Tests ebnet.

Gherkin ist eine domänenspezifische Sprache zum Schreiben von Akzeptanzkriterien, die fünf Hauptaussagen hat:

1. Scenario – ein Label für das zu beschreibende Verhalten
2. Given – der Anfangszustand des Szenarios
3. When – eine bestimmte Aktion, die der Benutzer ausführt
4. Then – ein testbares Ergebnis, in der Regel verursacht durch die Aktion in When
5. And – dies setzt einen der anderen drei Operatoren fort

Zusammen beschreiben diese Anweisungen alle Aktionen, die ein Benutzer ausführen muss, um eine Aufgabe zu erfüllen, und das Ergebnis dieser Aktionen.

Ein reales Gherkin-Beispiel könnte zum Beispiel so aussehen:

Scenario: User clicks the link
Given I am on the homepage
When I click the provided link
Then I should see the link click confirmation

Oder, um es zu verallgemeinern, so:

Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

Generell schreibt der Produktmanager Gherkin-Akzeptanzkriterien, bevor das Team mit der Arbeit an einem Feature beginnt. Akzeptanzkriterien in einer einfach zu lesenden, leicht zu verstehenden Struktur zu haben, macht es für Entwickler und Designer viel einfacher, den beabsichtigten Benutzerfluss zu verstehen. Dies ist an sich schon wertvoll, aber es ist nur ein kleiner Teil des Wertes von gut strukturiertem Gherkin. Schließlich gibt es viele effektive Möglichkeiten, Funktionsbeschreibungen zu schreiben (z. B.: As a ___ I want to ___ so that ___), die die Kommunikation erleichtern können.

Diese anderen Ansätze haben ihren Platz und sind in vielen Fällen mit Gherkin kompatibel. Sobald wir jedoch über die manuelle QS hinausgehen und in den Bereich des automatisierten Testens vordringen, kommt der wahre Wert von Gherkin zum Vorschein. Mit ein paar cleveren Techniken können die englischen Gherkin-Szenarien, die wir schreiben, automatisch in testbaren automatisierten Code übersetzt werden. Um zu sehen, was ich meine, lassen Sie uns einen kurzen Blick auf den großen Bruder von Gherkin werfen – Cucumber.

Reguläre Ausdrücke

Die Übersetzung von Gherkin-Szenarien in Code verwendet eine Technologie, die Reguläre Ausdrücke genannt wird, oder wie sie allgemein genannt wird, Regex.

Das Problem, das Regex löst, ist das Auffinden von bestimmten Wörtern, Phrasen oder Zeichen innerhalb eines Textes. Um dieses Ziel zu erreichen, haben die Schöpfer von Regex eine Reihe von Zeichen und Symbolen definiert, die die Logik hinter den übereinstimmenden Teilen des Textes darstellen. Zum Beispiel wird $ verwendet, um das Ende eines Strings zu markieren. Als solcher würde der reguläre Ausdruck fox$ auf silver fox passen (weil die letzten drei Buchstaben f-o-x sind), aber nicht auf foxy (weil der letzte Buchstabe y ist).

Cucumber verwendet Regex, um die von uns definierten Szenarien nach Gherkins Schlüsselwörtern zu durchsuchen (ScenarioGivenWhenThen und And) und die Phrasen, die ihnen folgen. Wenn Cucumber eine Phrase findet, die es in einem unserer Szenarien mit Hilfe von Regex erkennt, übersetzt es diese Phrase in Code, indem es etwas verwendet, das Step Definitions genannt wird.

Step Definitions

Step Definition Dateien sind wie ein Fremdsprachenwörterbuch. Sie geben unserer Testsuite eine Möglichkeit, englische Szenarioschritte in Code zu übersetzen, den wir ausführen können. In den meisten Teams schreiben die Entwickler, die das Feature bauen werden, die Schrittdefinitionen.

Schrittdefinitionsdateien sehen in etwa so aus:

Die erste Anweisung besagt: „Jedes Mal, wenn Sie die Zeichenkette ‚Ich gehe zur Homepage‘ finden, führen Sie die visit root_path-Funktion aus“.

Die zweite Anweisung besagt: „Jedes Mal, wenn du die Zeichenkette ‚Ich sollte die Willkommensnachricht sehen‘ findest, dann erwarten wir, dass die aktuelle Seite irgendwo den Text ‚Hello Cucumber‘ enthält.“

Jeder Schritt in einem Szenario sollte eine Schrittdefinition haben, damit die automatisierte Testsuite weiß, wie sie unser Englisch in Code übersetzen kann. Im Laufe der Zeit werden Sie Hunderte dieser Schrittdefinitionen schreiben, von denen viele in Ihrer gesamten Testsuite wiederverwendbar sind (wie der oben definierte erste Schritt).

Kaveat: Die Wiederverwendung von Funktionen ist nur möglich, wenn wir eine einzige Phrase für eine einzige Aktion verwenden. Wenn unsere Szenarien sowohlI go to the homepage als auch I visit the homepage austauschbar verwenden, dann müssen wir zwei separate Schrittdefinitionen für dieselbe Aktion pflegen. Dieser doppelte Code erschwert die Pflege unserer Testsuite und verstößt gegen das DRY-Prinzip (Don’t repeat yourself) der Softwareentwicklung.

Wenn unsere Anwendungen und unsere Testsuiten wachsen, wachsen auch unsere Schrittdefinitionen und die Anzahl der Szenarien mit. Das kann schnell unübersichtlich und überwältigend werden. Um unsere Testsuiten zu organisieren, verwenden wir Feature-Dateien.

Feature-Dateien

Um die Komplexität einer großen Testsuite in den Griff zu bekommen, fassen wir unsere Gherkin-Szenarien in Feature-Dateien zusammen. Feature-Dateien sind wie eine virtuelle Checkliste, um sicherzustellen, dass Ihre Software funktioniert. Zusätzlich zu den Szenarien, die zum Testen eines Features benötigt werden, enthalten Feature-Dateien auch eine kurze Beschreibung des Features und jegliche Geschäftsregeln oder zusätzliche Informationen, die helfen zu beschreiben, was das Feature tut.

Eine Feature-Datei könnte etwa so aussehen:

Feature: Some terse yet descriptive text of what is desired
Textual description of the business value of this feature
Business rules that govern the scope of the feature
Any additional information that will make the feature easier to understand
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too Scenario: A different situation
...

Eine Anwendung kann (und sollte) viele Feature-Dateien haben, um zu beschreiben, wie Ihre Features funktionieren. Diese Tests arbeiten zusammen, um Ihnen einen Überblick über den Zustand Ihrer Anwendung zu geben.

Ausgabe

Wenn Sie Ihre Testsuite auf der Kommandozeile mit Cucumber ausführen, erhalten Sie eine Ausgabe etwa wie diese:

$ cucumber -s
Using the default profile...
Feature: Hello CucumberScenario: User sees the welcome message
When I go to the login page
Then I should see the welcome message1 scenario (1 passed)
2 steps (2 passed)
0m0.148s

Oder für etwas Konkreteres:

$ cucumber -s
Using the default profile...
Feature: Google Homepage SearchScenario: User sees the header
Given I’m on the homepage
Then I see the headerScenario: User can search with "Google Search”
Given I’m on the homepage
When I type "random page” into the search field
And I click the Google Search button
Then I go to the random page search resultsScenario: User can search with "I’m Feeling Lucky”
Given I’m on the homepage
When I type "random page” into the search field
And I click the I’m Feeling Lucky button
Then I go to a random pageScenario: User can see the Terms and Conditions
...15 scenarios (15 passed)
87 Steps (87 passed)
0m3.141s

Ein Blick auf die Ausgabe beim Ausführen Ihrer Testsuite gibt Ihnen eine sofortige Möglichkeit, Ihre Anwendung zu überprüfen. Es kann zeigen, wo Ihre Änderungen einen Teil der alten Funktionalität zerstört haben oder wo die neue Funktionalität nicht wie vorgesehen funktioniert. Das macht es einfach, diese Probleme zu finden und zu beheben, so dass Sie mit Zuversicht ausliefern können.

Wrapping Up

Die Verwendung von Gherkin zum Schreiben von Szenarien macht es einfach, die Abläufe zu zeigen, die das Produkt haben muss. Feature-Dateien helfen dabei, diese Abläufe in logische Abschnitte zu organisieren. Cucumber scannt diese Abschnitte und zeigt uns live an, welche Teile unserer Software funktionieren und welche nicht.

Eine vollständige Testsuite, in der jedes Feature eine Feature-Datei und eine Reihe von Szenarien hat, ist ein mächtiges Werkzeug. Es macht es einfach, Fehler in neuen Funktionen zu finden, die Einführung von Fehlern in alten Funktionen zu vermeiden und den Fortschritt mit den Beteiligten zu kommunizieren. Langer Rede kurzer Sinn, es automatisiert einige der größten Verzögerungen zwischen der Erstellung eines Features und der Übergabe an die Benutzer.

Die Verwendung von Gherkin und Cucumber ist nicht der einzige Weg, um automatisierte Akzeptanzkriterien-Tests zu erstellen, aber es ist eine Struktur, die leicht zu erweitern ist. Sie können sofort mit dem Schreiben von Gherkin beginnen und wenn Ihr Team reift und wächst, können Sie Step-Dateien und automatisierte Tests mit Cucumber hinzufügen. Wenn sie effektiv eingesetzt werden, geben uns Cucumber und Gherkin einen klaren (und iterativen!) Weg zu vollständigen und automatisierten Unit-Tests.