BDD mit Cucumber & Java: Warum deine Tests endlich eine Geschichte erzählen sollten

Für viele wahrscheinlich schon ein alter Hut oder besser gesagt Alltag. Heute gibt es eine Einführung in Cucumber.

Warum eigentlich Cucumber? (Und was ist dieses BDD?)

Im klassischen Entwicklungsalltag kennen wir das Problem: Die Business-Seite schreibt Anforderungen, die Entwickler schreiben Code und am Ende merken alle beim Review, dass man aneinander vorbeigeredet hat. Hier kommt Behavior Driven Development (BDD) ins Spiel.

BDD: Die gemeinsame Sprache

BDD ist kein reines Testing-Konzept, sondern eine Methode, um die Kommunikation zwischen Product Ownern, Testern und Entwicklern zu verbessern. Anstatt technischer Spezifikationen schreiben wir User Stories in einer Form, die jeder lesen kann. Wir definieren das Verhalten (Behavior) der Software aus Sicht des Nutzers, bevor wir auch nur eine Zeile Produktivcode schreiben.

Der Platz von Cucumber im Ökosystem

Cucumber ist das Tool, das diese lesbaren Texte (wir nennen sie Features) in automatisierte Tests verwandelt. Es schlägt die Brücke zwischen der menschlichen Sprache und deinem Test-Code.

Der Vorteil: Deine Dokumentation ist gleichzeitig dein Test-Set. Wenn die Doku veraltet, schlagen die Tests fehl. “Living Documentation” in Reinform.

Gherkin: Die Brücke zwischen Mensch und Code

Damit Cucumber versteht, was wir von unserer Software erwarten, nutzen wir eine strukturierte Sprache namens Gherkin. Gherkin ist so konzipiert, dass sie für Business-Leute lesbar ist, aber gleichzeitig genug Struktur bietet, um sie automatisiert zu verarbeiten.

Die Anatomie eines Szenarios

Ein Gherkin-Dokument (meist eine .feature-Datei) besteht aus verschiedenen Schlüsselwörtern. Die wichtigsten für den Start sind:

• Feature: Beschreibt die übergeordnete Funktionalität (z. B. “Benutzer-Login”).
• Scenario: Ein konkreter Anwendungsfall oder ein Testfall (z. B. “Erfolgreicher Login mit korrekten Daten”).
• Given (Angenommen): Beschreibt den Ausgangszustand oder den Kontext. Wo befinden wir uns? Was ist bereits passiert?
• When (Wenn): Hier findet die eigentliche Interaktion statt. Was tut der Benutzer?
• Then (Dann): Das erwartete Ergebnis. Was soll passieren? Was prüfen wir?
• And / But (Und / Aber): Hilfswörter, um Schritte logisch zu verbinden, ohne die Lesbarkeit durch ständige Wiederholung von “Given” oder “Then” zu stören.

Ein Beispiel aus der Praxis

So sieht das Ganze dann im Editor aus:

Feature: Warenkorb-Funktionalität

  Scenario: Ein Produkt zum leeren Warenkorb hinzufügen
    Given ich befinde mich auf der Produktdetailseite von "Kaffee-Bohnen"
    When ich auf den Button "In den Warenkorb" klicke
    Then sollte die Anzahl der Artikel im Warenkorb "1" sein
    And mir sollte die Bestätigung "Produkt hinzugefügt" angezeigt werden

Warum dieser Aufbau? In Projekten sehe ich oft, dass Teams in den Gherkin-Steps zu technisch werden (z. B. “When ich auf das div mit der ID #btn-123 klicke”). Vermeide das! Gherkin soll das Was beschreiben, nicht das Wie. Die technische Umsetzung gehört in den Code, nicht in die Feature-Datei.

Hands-on: Das erste Feature-File anlegen

Genug der Theorie! Lass uns das erste Feature-File in ein Projekt integrieren. Damit das Ganze funktioniert, brauchen wir eine saubere Ordnerstruktur und – ganz wichtig – die Unterstützung unserer IDE.

Das Tooling: IntelliJ IDEA Plugins

Wenn du IntelliJ nutzt (was im Java-Umfeld der Standard ist), solltest du sicherstellen, dass zwei Plugins installiert sind:

1. Gherkin: Sorgt für das Syntax-Highlighting der .feature-Dateien.
2. Cucumber for Java: Das ist der “Magier” im Hintergrund. Er erkennt, ob zu einem Text-Schritt bereits Code existiert, lässt dich per Strg + Klick direkt zur Implementierung springen und hilft dir, fehlende Step-Definitions zu generieren.

Wo gehört die Datei hin?

In einem Standard-Maven- oder Gradle-Projekt legen wir unsere Feature-Dateien unter src/test/resources ab. Ein bewährtes Muster ist: src/test/resources/features/[Funktionsbereich]/login.feature

Unser erstes Szenario

Erstelle eine Datei namens login.feature und fülle sie mit Leben. Wir nehmen ein klassisches Beispiel:

@UI @Login
Feature: Benutzer-Anmeldung
  Als registrierter Nutzer möchte ich mich einloggen,
  um auf meinen persönlichen Bereich zuzugreifen.

  Scenario: Erfolgreicher Login mit validen Daten
    Given ich bin auf der Login-Seite
    When ich gebe den Benutzernamen "julian" und das Passwort "geheim123" ein
    And ich klicke auf den Login-Button
    Then werde ich zum Dashboard weitergeleitet
    And ich sehe die Willkommensnachricht "Hallo Julian"

Tipp: Achte auf die Tags (die Wörter mit @ am Anfang). Mit @UI oder @Login kannst du später gezielt nur bestimmte Tests ausführen. Das spart Zeit, wenn deine Testsuite irgendwann hunderte Szenarien umfasst.

Hinter den Kulissen: Step Definitions

Die Feature-Datei ist das “Was”, die Step Definitions sind das “Wie”. In Java erstellen wir dafür einfache Klassen, in denen wir die Gherkin-Schritte mit Methoden verknüpfen.

Cucumber nutzt dafür Annotationen wie @Given, @When und @Then, die über Regular Expressions oder die moderneren Cucumber Expressions mit dem Text in deiner .feature-Datei gematcht werden.

So sieht der “Glue Code” aus

Hier ist die Implementierung für unser Login-Szenario:

import io.cucumber.java.en.Given;
import io.cucumber.java.en.When;
import io.cucumber.java.en.Then;
import static org.assertj.core.api.Assertions.assertThat;

public class LoginSteps {

    // Ein Mock oder ein Page Object für die eigentliche Logik
    private LoginPage loginPage = new LoginPage();

    @Given("ich bin auf der Login-Seite")
    public void ichBinAufDerLoginPage() {
        loginPage.open();
    }

    @When("ich gebe den Benutzernamen {string} und das Passwort {string} ein")
    public void ichGebeDatenEin(String user, String pass) {
        loginPage.enterCredentials(user, pass);
    }

    @When("ich klicke auf den Login-Button")
    public void ichKlickeLogin() {
        loginPage.clickLogin();
    }

    @Then("werde ich zum Dashboard weitergeleitet")
    public void checkDashboard() {
        assertThat(loginPage.isDashboardVisible()).isTrue();
    }

    @Then("ich sehe die Willkommensnachricht {string}")
    public void checkWelcomeMessage(String expectedMessage) {
        String actualMessage = loginPage.getWelcomeText();
        assertThat(actualMessage).isEqualTo(expectedMessage);
    }
}

Was passiert hier technisch?

1. Parameter-Passing: Merkst du die {string} Platzhalter? Cucumber extrahiert den Text aus den Anführungszeichen deines Gherkin-Files und übergibt ihn direkt als Argument in deine Java-Methode. Das macht deine Tests extrem wiederverwendbar.
2. Die Brücke: IntelliJ zeigt dir (wenn die Plugins installiert sind) links neben der Methode ein kleines grünes Symbol oder das Cucumber-Logo. Damit weißt du: Der Link zwischen Text und Code steht.

Tipp: Hüte dich davor, die gesamte Testlogik (wie Selenium-Klicks oder API-Calls) direkt in die Step-Definition-Klasse zu schreiben. Nutze das Page Object Pattern. Die Step-Definition sollte nur die Orchestrierung übernehmen – die Details, wie ein Button gefunden wird, gehören in eine separate Page-Klasse. Das hält deinen Code wartbar.

Best Practices & Stolperfallen

Cucumber ist ein scharfes Messer: In den richtigen Händen schneidet es perfekt, in den falschen tut es weh. Damit dein Test-Code nicht zum Wartungsalbtraum wird, hier meine wichtigsten Tipps:

1. Deklarativ statt Imperativ schreiben

Schreibe deine Gherkin-Schritte so, dass sie beschreiben, was der Nutzer tut, nicht wie er es technisch macht.

• Schlecht (Imperativ): When ich in das Feld mit der ID "user" den Text "admin" tippe und auf das Element ".submit-btn" klicke
• Gut (Deklarativ): When ich mich mit meinen Administrator-Zugangsdaten anmelde

2. Cucumber ist kein Ersatz für Unit Tests

Ein häufiger Fehler: Alles mit Cucumber testen zu wollen. Cucumber-Tests laufen meist über das UI oder API und sind deutlich langsamer als Unit Tests. Nutze Cucumber für die “Happy Paths” und wichtige Business-Logik. Die 50 verschiedenen Validierungsfehler eines Formulars testest du besser mit schnellen JUnit-Tests.

3. Vermeide “Gherkin-Spaghetti”

Wenn ein Szenario 20 Schritte hat, liest es niemand mehr. Wenn du merkst, dass deine Feature-Files zu lang werden, nutze das Schlüsselwort Background für wiederkehrende Setups oder versuche, Schritte logisch zusammenzufassen.

Tipp: Wenn der Product Owner deine Feature-Files nicht liest, ist Cucumber wahrscheinlich das falsche Tool für dein Projekt. Der größte Mehrwert ist die gemeinsame Sprache.

Fazit

Cucumber und BDD sind mächtige Werkzeuge, um die Lücke zwischen Business und IT zu schließen. Es geht nicht nur darum, grüne Haken in deiner Pipeline zu sehen, sondern sicherzustellen, dass wir das Richtige bauen – und zwar so, dass es jeder im Team versteht.

Für den Start mit Java und IntelliJ hast du nun das Handwerkszeug: Klare Gherkin-Syntax, sauberer Glue-Code und ein Fokus auf wartbare Step-Definitions. Fang klein an, schreib dein erstes Szenario und lass die Dokumentation für dich arbeiten!