Gherkin Tutorial: BDD mit Given-When-Then & Praxisbeispiele [2026]

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

Nachteile von Tosca

• Hohe Lizenzkosten
  • Tosca gehört zu einem der teuersten Testautomatisierungstools auf dem Markt
  • Für kleinere Unternehmen eher unrentabel
• Eingeschränkte Flexibilität
  • Für Entwickler, die sich mehr Eigenkontrolle via Code wünschen, ist dieses Tool weniger geeignet
• Höherer Ressourcenverbrauch
  • Da es sich bei Tosca um eine große Suite handelt, die allerlei Nebenfunktionen mitbringt, benötigt es eine leistungsfähigere Infrastruktur, insbesondere für große Testumgebungen mit vielen parallelen Testläufen
• Eingeschränkte Open-Source Integration
  • Während Tosca gut in kommerzielle Lösungen wie beispielsweise SAP oder Azure DevOps integriert ist, ist die Integration zu Open-Source-Tools wie beispielsweise Selenium oder Playwright eingeschränkt.
• Proprietäre Technologie (Vendor Lock-in)
  • Ist erst einmal eine Testautomatisierung mit Tosca aufgesetzt worden, so kann diese nicht oder nur mit sehr viel Aufwand auf andere Tools übertragen werden
• Eingeschränkte Unterstützung durch die Community
  • Da es sich um kein Open-Source-Projekt handelt, kann die Community nur bedingt einem behilflich sein. Jedoch steht einem der offizielle Support zur Rat und Tat zur Verfügung
• Performance-Einbußen bei großen Testobjekten
  • Bei sehr großen und komplexen Testfällen kann die Performance rapide einknicken

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.

FAQ: Häufig gestellte Fragen zu Gherkin

Was ist der Unterschied zwischen BDD und TDD?

BDD beschreibt erwartetes Verhalten aus Nutzersicht mit Given-When-Then. TDD prüft technische Korrektheit mit Unit-Tests. Beide ergänzen sich: BDD für Akzeptanztests, TDD für die Komponentenebene. Mehr dazu in unserem BDD-Grundlagen-Artikel.

Welche Testautomatisierungs-Tools unterstützen Gherkin?

Cucumber (Java), Playwright mit cucumber-js, Cypress mit cypress-cucumber-preprocessor und Robot Framework.

Wie schreibe ich gute Gherkin-Szenarien?

Jedes Szenario testet genau ein Verhalten. Given beschreibt den Ausgangszustand, When die Aktion, Then das Ergebnis. Halte Szenarien auf 5 bis 7 Steps.

Kann ich Gherkin ohne Cucumber verwenden?

Ja. Playwright, Cypress und andere Frameworks haben eigene Gherkin-Adapter. Entscheidend ist, dass das Team die Grundregeln der Testautomatisierung beherrscht.

Was sind die Grenzen von Gherkin?

Gherkin eignet sich für Akzeptanztests und E2E-Tests. Für Unit-Tests, Performance-Tests oder API-Tests sind andere Ansätze effizienter.

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.