Cucumber – Das kollaborative Tool für Behavior Driven Development

Cucumber ist ein Open Source (BDD-Framework) Behavior-Driven-Development-Werkzeug bzw. Framework (Siehe „Verhaltensgetriebene Softwareentwicklung“ – Thematisiere ich definitiv und explizit in einem zukünftigen Beitrag) zur textuellen Spezifikation von Anforderungen an Software und zum automatisierten Testing bzw. mit dem sich (unter anderem) sehr gut lesbare, gut zu wartbare und elegante Akzeptanz-Tests für Web-Anwendungen schreiben lassen.

Cucumber wurde ursprünglich in der Programmiersprache Ruby für Ruby-Anwendungen geschrieben. In der Zwischenzeit unterstützt es aber auch andere Programmiersprachen wie Java und alle anderen auf der Java Virtual Machine gängigen Programmiersprachen sowie C++ und JavaScript. Darüber hinaus gibt es Projekte, die Cucumber noch für weitere Programmiersprachen zur Verfügung stellen und sich als Teil der Cucumber-Familie sehen. Darunter beispielsweise SpecFlow, eine Implementierung für C#.

Wie funktioniert Cucumber?

Wie auch bei den meisten anderen BDD-Frameworks werden in Cucumber Funktionalitäten mittels der Beschreibungssprache „Gherkin“ beschrieben. Gherkin verwendet natürliche Schriftsprache als Grundlage. Lediglich bestimmte Schlüsselwörter werden besonders behandelt.

Gherkin

Gherkin ist die Sprache, die Cucumber verwendet, um Testfälle zu definieren. Sie ist so konzipiert, dass sie sich nicht-technisch und für den Menschen lesbar gestaltet. Es beschreibt Anwendungsfälle in Bezug auf ein Softwaresystem. Der Zweck hinter der Gherkin-Syntax ist die Förderung verhaltensorientierter Entwicklungspraktiken in einem Entwicklungsteam, einschließlich Geschäftsanalysten und Managern. Sie zielt darauf ab, bereits in den ersten Phasen der Anforderungsdefinition durch die Geschäftsleitung und in anderen Phasen des Entwicklungslebenszyklus einer Anwendung feste, eindeutige Anforderungen durchzusetzen.

Syntax

Die Syntax ist ähnlich wie bei Python zeilenorientiert aufgebaut. Die Struktur einer Datei wird durch Leerzeichen und andere Steuerzeichen definiert. # wird als Zeilen bzw. Kommentarzeichen verwendet und kann an jeder beliebigen Stelle in einer Datei stehen. Anweisungen sind jede nicht leere und nicht kommentierte Zeile. Sie bestehen aus einem konkreten Gherkin-Schlüsselwort, gefolgt von einer Zeichenkette.

Alle Gherkin-Dateien haben die Dateierweiterung .feature. Sie enthalten eine einzelne Feature-Definition für das zu testende System und sind ein ausführbares Testskript.

Neben der Bereitstellung eines Skripts für automatisierte Tests ist die Syntax von Gherkin so konzipiert, dass sie eine einfache Dokumentation des zu testenden Codes ermöglicht. Gherkin unterstützt derzeit Schlüsselwörter in Dutzenden von Sprachen.

Schlüsselwörter der Gherkin Sprache

  • Feature: Name bzw. die Bezeichnung des Features
  • Rule: Regeln des Features
  • Example oder Scenario: Die Bezeichnung des Szenarios (Beispielsweise „Die erfolgreiche Anmeldung mit gültigen Anmeldeinformationen.“)
  • Given, When, Then, And, But für die steps (oder *)- Vorbedingungen (Gegeben sei), die Aktion, die ausgeführt wird bzw. die Erweiterung durch andere Schlüsselwörter um die Aktion die ausgeführt wird zu ergänzen bzw. zu erweitern. (Der User gibt beispielsweise seine Zugangsdaten, Username and Password ein), gefolgt von der erwarteten Reaktion des Systems (Beispielsweise die Nachricht, bei einem erfolgreichen Login.)
  • Background – Ein Background ermöglicht es einem, den nachfolgenden Scenarios einen gewissen Kontext hinzuzufügen. Es kann einen oder mehrere Vorgegebene Schritte enthalten, die vor jedem Scenario aber nach jedem Before hook ausgeführt werden.
  • Scenario Outline oder Scenario Template – Damit lässt sich dasselbe Szenario mehrmals mit unterschiedlichen Wertekombinationen ausführen.
  • Examples oder Scenarios – Eine Scenario Outline muss einen oder mehrere Abschnitte mit Examples bzw. Scenarios enthalten. Sie dienen als Steps bzw. Interpretationsvorlage, die nie direkt ausgeführt werden. Stattdessen wird die Szenariogliederung einmal für jede Zeile mit den darunter liegenden Abschnitten von Examples ausgeführt.

Gherkin in deutscher Sprache

Um eine Funktionalität auf Deutsch zu schreiben, muss am Beginn des Features # language: de angegeben werden. Damit sind u.A. folgende deutsche Schlüsselwörter verfügbar:

  • Funktionalität
  • Grundlage
  • Szenario
  • Szenariogrundriss
  • Beispiele
  • Angenommen
  • Gegeben sei
  • Wenn
  • Dann
  • Und und Aber, sowie *

Die Command line (CL)

Cucumber verfügt über eine integrierte Kommandozeilenschnittstelle, die eine umfassende Liste von Anweisungen enthält. Wie die meisten Kommandozeilen-Tools bietet Cucumber die Option –help an, die eine Zusammenfassung der Befehle liefert, die diese Command Line akzeptiert.

$ cucumber --help
        -r, --require LIBRARY|DIR        Require files before executing the features.
        --i18n LANG                      List keywords for in a particular language.
                                         Run with "--i18n help" to see all languages.
        -f, --format FORMAT              How to format features (Default: pretty).
        -o, --out [FILE|DIR]             Write output to a file/directory instead of
        ...

Fazit

Gherkin ist nicht nur zum Schreiben von automatisierten Tests geeignet. Man kann Gherkin grundsätzlich auch dazu verwenden, um strukturierte Tests zu erstellen, die man später als Projektdokumentation verwendet kann. Erst die Eigenschaft, strukturiert zu sein, gibt uns die Möglichkeit zu automatisieren.

Sowohl die Sprache Gherkin wie auch das Tool Cucumber, bieten weitaus mehr Funktionalitäten, die ich hier nicht thematisiert habe. Zumal ich auch recht frisch in dieses Thema eingestiegen bin. So ist beispielsweise ein Datengetriebenes Szenario mithilfe von Tabellen möglich. Fernab können verschiedene Schritte, die im Prinzip das Gleiche tun, über Platzhalter definiert werden.

Um solche und weitere Vorteile zu nutzen, ist neben Cucumber oder anderen Testtools vor allem Disziplin beim Verfassen der Dokumentation bzw. der Gherkin Dokumente gefragt. Gleichzeitig müssen die formulierten Schritte präzise genug sein, um die gewünschten Verhaltensweisen ausreichend genau zu beschreiben. Ansonsten zerfällt die Abstraktion und Gherkin Dokumente werden lediglich zu etwas besser lesbaren Testskripten statt dem Ansatz des BDD zu folgen.

Cucumber lässt sich auch mit IntelliJ nutzen. Aber darüber gibt es dann in naher Zukunft einen weiteren Beitrag.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.