Gherkin – “Verstehen Sie mich jetzt?”

Kennen Sie das Gefühl, wenn Sie eine technische Dokumentation lesen und sich fragen, ob sie vielleicht in einer Geheimsprache verfasst wurde? So in etwa: „Initialisieren Sie das Singleton-Muster mit Lazy Loading, um die Factory Dependency Injection im Middleware-Stack zu kapseln…“ – äh, bitte was?

Für Entwickler mag das noch Sinn ergeben, aber für Tester, Product Owner oder Fachabteilungen klingt es häufig wie eine Zauberformel aus einem verlorenen Harry-Potter-Band. Hier kommt Gherkin ins Spiel. Eine Sprache, die Testfälle in einfache, verständliche Sätze packt – sodass nicht nur Entwickler, sondern auch der Rest des Teams versteht, wie sich die Software verhält und was getestet wird.

Klingt nach Magie? Ist aber einfach nur smartes Design.

Was ist Gherkin?

Gherkin ist die Sprache hinter BDD-Frameworks wie Cucumber oder Behave. Ihre Besonderheit: Sie folgt einer einfachen Given-When-Then-Struktur:

Feature: Make a coffee 
  As a coffee-lover 
  I want to brew an espresso 
  So that I can stay awake the entire day 
  Scenario: Brewing 
    Given the coffee machine is turned on 
    When I press the 'espresso' button 
    Then a cup of espresso comes out of the machine

Dieses Beispiel zeigt: Gherkin beschreibt Verhalten (behavior) in einer Weise, die auch ohne technische Kenntnisse verständlich ist. Entwickler, Tester und Stakeholder sprechen damit eine gemeinsame Sprache – eine, die sich gleichzeitig für die Testautomatisierung eignet.

Interessanterweise ähnelt diese Struktur stark den User Stories, die in der Anforderungsanalyse genutzt werden. Auch dort findet man das Muster: „Als [Rolle] möchte ich [Funktion], damit [Nutzen]“. Diese Parallele zeigt, wie eng Anforderungsbeschreibung und Testbeschreibung miteinander verknüpft sind.

Die Bausteine von Gherkin

Gherkin-Syntax ist simpel, aber effektiv. Hier sind die wichtigsten Schlüsselwörter:

• Feature – Beschreibt die übergeordnete Funktionalität.
• Scenario – Stellt einen konkreten Testfall dar.
• Given – Definiert den Ausgangszustand.
• When – Beschreibt eine Aktion oder ein Ereignis.
• Then – Prüft das erwartete Ergebnis.
• And/But – Erweitern die Given-, When- oder Then-Schritte.

Wer es strukturierter mag, kann auch Szenariovorlagen (Scenario Outline) mit Beispielwerten nutzen, um datengetriebene Tests zu ermöglichen:

Scenario Outline: Coffee price calculation 
  Given the price per cup is <Price> 
  When I order <Quantity> cups 
  Then the total amount should be <Total> 
  Examples: 
    | Price | Quantity | Total | 
    | 2.50  | 2        | 5.00  | 
    | 3.00  | 3        | 9.00  |

Gherkin in der Praxis

In der Theorie klingt Gherkin wunderbar, aber wie setzt man es in der Praxis um? Der Schlüssel ist die Verknüpfung mit einem BDD-Testframework wie Cucumber. Das funktioniert über sogenannte Step Definitions – also Methoden, die den Gherkin-Schritten zugeordnet sind.

Podcast: Cucumber in der Praxis: Cucumber in der Praxis

Verwendung von Feature-Files in Java

In Java werden Gherkin Feature-Files im Ordner src/test/resources/features/ gespeichert und mit Cucumber ausgeführt. Hier ein Beispiel:

Feature-Datei (coffee.feature):

Feature: Make a coffee 
    Scenario: Brewing 
      Given the coffee machine is turned on 
      When I press the 'espresso' button 
      Then a cup of espresso comes out of the machine

Step Definitions (CoffeeSteps.java):

import io.cucumber.java.en.*; 
import static org.junit.jupiter.api.Assertions.*; 
public class CoffeeSteps { 
    private boolean machineOn = false; 
    private String coffee = ""; 
    @Given("the coffee machine is turned on") 
    public void theCoffeeMachineIsTurnedOn() { 
        machineOn = true; 
    } 
    @When("I press the 'espresso' button") 
    public void iPressTheEspressoButton() { 
        if (machineOn) { 
            coffee = "Espresso"; 
        } 
    } 
    @Then("a cup of espresso comes out of the machine") 
    public void aCupOfEspressoComesOutOfTheMachine() { 
        assertEquals("Espresso", coffee); 
    } 
}

Gherkin mit Playwright

Für UI-Tests kann Playwright ebenfalls mit Gherkin genutzt werden. Hier ein Beispiel für einen Login-Test:

Feature-Datei (login.feature):

Feature: Login functionality 
  Scenario: Successful login 
    Given I open the login page 
    When I enter valid credentials 
    Then I should see the homepage

Step Definitions (login.steps.ts):

import { Given, When, Then } from '@cucumber/cucumber'; 
import { expect } from '@playwright/test'; 
import { page } from '../support/world'; 
Given('I open the login page', async () => { 
    await page.goto('https://example.com/login'); 
}); 
When('I enter valid credentials', async () => { 
    await page.fill('#username', 'testuser'); 
    await page.fill('#password', 'password123'); 
    await page.click('#login-button'); 
}); 
Then('I should see the homepage', async () => { 
    await expect(page).toHaveURL('https://example.com/home'); 
});

Dies kombiniert die leistungsfähige Browserautomatisierung von Playwright mit der Gherkin-Syntax für leicht verständliche UI-Tests.

Best Practices für Gherkin-Tests

Damit Gherkin-Tests tatsächlich die Entwicklung erleichtern und nicht verkomplizieren, sind einige Best Practices zu beachten:

1. Klar und präzise formulieren
   Ein Given-When-Then-Szenario sollte so verständlich sein, dass es auch ein Fachfremder nachvollziehen kann. Vermeide technische Details in den Szenarien – die gehören in die Step Definitions.
2. Atomic Scenarios schreiben
   Jedes Szenario sollte genau einen Ablauf testen. Wenn ein Test zu viele „Unds“ enthält, könnte er in mehrere kleinere Tests aufgeteilt werden.
3. Step Definitions wiederverwenden
   Gute Gherkin-Tests nutzen generische Schritte, die in mehreren Szenarien wiederverwendet werden können. So bleibt der Code übersichtlich.
4. Nicht alle Tests müssen in Gherkin sein
   Gherkin ist ideal für Akzeptanztests, aber nicht immer für Unit- oder Integrationstests notwendig. Hier reicht oft ein klassisches Testframework wie JUnit oder TestNG.
5. Tests automatisieren und in CI/CD einbinden
   Gherkin-Szenarien sollten automatisiert und in Continuous Integration (CI) Pipelines eingebunden werden, um Regressionen frühzeitig zu erkennen.

Fazit zu Gherkin

Gherkin bietet eine klare, strukturierte Möglichkeit, Anforderungen und Tests in einer einheitlichen Sprache zu formulieren. Dadurch verbessert es die Zusammenarbeit zwischen Entwicklern, Testern und Fachabteilungen erheblich. Die Nähe zu User Stories erleichtert die Ableitung von Testfällen, wodurch Software bereits in der Entwicklungsphase effektiver getestet werden kann. Durch die enge Verbindung mit BDD-Frameworks wie Cucumber oder Playwright lassen sich Tests direkt aus verständlichen Szenarien ableiten, was zu einer besseren Nachvollziehbarkeit führt. Die klare Given-When-Then-Struktur macht Testfälle nicht nur verständlicher, sondern auch einfacher wartbar. Wer Gherkin konsequent nutzt, kann eine robuste Teststrategie schaffen, die langfristig zu höherer Softwarequalität und einer effizienteren Zusammenarbeit im Team führt.