Was ist Cucumber
Cucumber ist ein spezielles Framework, welches die Automatisierung der mit der Gherkin Sprache formulierten (Test)-Szenarien nach dem BDD-Prinzip unterstützt. Dabei fungiert Cucumber weniger als ein Testautomatisierungsframework, sondern viel mehr als ein Adapter-Framework, welches die einzelnen Szenario-Schritte der Gherkin Feature Files mit der zugehörigen Implementierung der Testautomatisierung verknüpft und ausführt.
Die eigentliche Automatisierung der Testschritte ist nicht die Aufgabe von Cucumber, sondern von dem gewählten Testframework gemäß der zugehörigen Stufe der Test-Pyramide – es kann sich folglich um eine Testautomatisierung auf der UI-Ebene mit Frameworks wie Selenium handeln, aber auch genauso gut um die Testautomatisierung auf der API Ebene mit Frameworks wie Rest-assured.
Das Cucumber Framework ist erfreulicherweise in allen gängigen Programmiersprachen umgesetzt und steht damit den Software Entwicklern und Testautomatisierern in der gewünschten Entwicklungsumgebung zur Verfügung. Die Übersicht aller sprachspezifischen Implementierungen findet man auf der offiziellen Cucumber Web Seite unter folgendem Link.
Besonders beliebt sind die Umsetzungen für folgende Programmiersprachen:
- Java: Cucumber-JVM
- C#: SpecFlow
- Python: Behave
- Ruby: Cucumber.rb
- JavaScript: Cucumber.js
Funktionsweise
Das Cucumber Framework bietet die Möglichkeit an, über einen Cucumber Runner die angegebenen Gherkin Feature Files auszulesen und anhand der inhaltlichen(!) Bezeichnung der darin enthaltenen Szenario-Schritte die zugehörigen Implementierungen der Automatisierung zu finden und auszuführen.
Das Auffinden der zugehörigen Implementierungen erfolgt anhand von Mappings, die in vielen Sprachen wie Java anhand von Annotationen bereitgestellt werden. Für die Beschreibung der Annotationen wird entweder eine spezielle „Cucumber Expression“ Syntax verwendet oder die regulären Ausdrücke eingesetzt. Beide Methodiken haben aber eins gemeinsam: die Beschreibung der Mapping-Regeln erfolgt unter starker Einbeziehung der originalen Inhalte der Gherkin-Schritte, die man mit einer gewissen Unschärfe versieht, um eine zumindest minimale Robustheit zu ermöglichen und zusätzlich noch die Extraktion der Parametervariablen zu unterstützen.
Dennoch muss an dieser Stelle auf die fundamentale Schwäche des gesamten Ansatzes hingewiesen werden. Durch die starke Entkopplung der nicht-formalen Gherkin-Spezifikation der Szenarien von der Implementierung ihrer Testautomatisierung, erfolgt die Verknüpfung dieser beiden Teile sehr lose anhand von Inhalt. Das bedingt wiederum eine sehr hohe Instabilität der Mappings selbst bei minimalen Abweichungen der verwendeten sprachlichen Formulierungen der Gherkin Schritte.
Aus den genannten Gründen gilt daher folgender Grundsatz: die Verwendung einer einfachen Sprache wie Gherkin zur nicht-formalen Beschreibung der Szenarien erleichtert die Kommunikation in agilen Teams enorm, erschwert jedoch eine robuste, stabile und wiederverwendbare Testautomatisierung. Aus diesem Grund empfiehlt es sich die gewählten Bezeichnungen der Gherkin Schritte möglichst homogen zu halten.
Das nachfolgende Beispiel veranschaulicht die Annotation zur Herstellung eines Mappings in Java mittels eines regulären Ausdrucks auf den ursprünglichen Gherkin Schritt:
@Given(„^Ich navigiere zur Login-Seite$“)
public void navigateToLoginPage()
{ // beliebige Umsetzung z.B. mit Selenium Framework }
Falls beim nächsten Szenario eine leicht abweichende Formulierung „Ich gehe zur Login-Seite“ verwendet wird, kann Cucumber Runner nicht mehr automatisch den zweiten Schritt auf die gleiche Implementierung mappen. Dafür muss man entweder den regulären Ausdruck unschärfer gestalten oder die Formulierung des Gherkin Schrittes angleichen. Eine Duplizierung der Implementierung sollte man dagegen soweit wie möglich vermeiden.
Weitere Informationen
Offizielle Webseite: https://cucumber.io/
Schulungen
Behavior Driven Development (BDD) mit Cucumber