Cucumber Testing liest fachliche Szenarien aus `.feature`-Dateien, verbindet jeden Schritt mit Programmcode und meldet das Ergebnis. Die Szenarien nutzen meist Gherkin Syntax, die Klartext durch Schlüsselwörter strukturiert. Step Definitions stellen danach den technischen Zugang zu Anwendung, API oder App her. Cucumber selbst enthält weder Browsersteuerung noch Assertion-Bibliothek (Cucumber, 2026). Im Behavior Driven Development folgt diese Ausführung auf gemeinsam entdeckte und formulierte Beispiele. Eine nachträgliche Cucumber-Suite kann nützliche Testautomatisierung sein, belegt jedoch keine vorgelagerte BDD-Zusammenarbeit. Diese Trennung verhindert falsche Erwartungen an Runner und Treiber.

Kurz gefasst: Cucumber verarbeitet Gherkin-Dateien, erzeugt interne Testfälle und ordnet jedem Schritt eine Step Definition zu. Treiber und Testbibliotheken übernehmen Browser-, API- oder App-Zugriffe sowie Assertions. Der technische Ablauf umfasst 8 Kernstationen. Gemeinsame Discovery, klare Fachbegriffe und isolierter Zustand entscheiden über den langfristigen Nutzen.

Abbildung 1: Die vier Schichten von Gherkin bis zum Systemzugriff.

Was ist Cucumber Testing?

Cucumber Testing ist die Ausführung strukturierter Verhaltensbeispiele durch Cucumber. Das Open-Source-Werkzeug liest ausführbare Klartext-Spezifikationen, sucht passenden Automationscode und meldet jedes Szenario mit klarer Zuordnung als erfolgreich oder fehlerhaft (Cucumber, 2026). Die aktuelle Installationsübersicht trennt Implementierungen in 4 Pflegekategorien (Cucumber, 2026).

Gherkin gibt dem Text seine Struktur. Cucumber verarbeitet diese Struktur. Step Definitions verbinden die fachlichen Sätze mit Methoden in Java, Kotlin, JavaScript, Ruby oder einer anderen unterstützten Umgebung. Der technische Zugang zum System liegt in diesen Methoden und den angebundenen Bibliotheken.

Die Cucumber-Dokumentation trennt Werkzeugnutzung von BDD Testing, das gemeinsame Discovery vor der Automation verlangt. Eine Cucumber-Suite nach fertiger Implementierung ist Testautomatisierung, aber für sich kein Beleg eines BDD-Prozesses (Cucumber, 2026).

Der Unterschied ist praktisch relevant. Ein Team kann Gherkin nach fertiger Implementierung schreiben und mit Cucumber ausführen. Es besitzt dann lesbare Regressionstests. Ein BDD-Prozess entsteht erst, wenn Fachseite, Entwicklung und Testing die Beispiele vor der Umsetzung gemeinsam klären.

Wie wird eine Feature-Datei ausgeführt?

Abbildung 2: Die fünf Kernstationen der Cucumber-Ausführung.

Eine `.feature`-Datei durchläuft 8 Kernstationen vom Text bis zum Ergebnis. Gherkin 42.0.1 beschreibt Scanner, Tokens, Syntaxbaum und Pickles; die Cucumber-API dokumentiert Hooks, Step-Matching und Status (Gherkin Repository, 2026). Jede Examples-Datenzeile erzeugt dabei eine eigene getrennte Szenarioausführung im aktuellen technischen Modell.

1. Der Scanner zerlegt den Inhalt der `.feature`-Datei in Tokens.

2. Der Parser erzeugt daraus einen Abstract Syntax Tree, kurz AST.

3. Der Compiler übersetzt den AST in Pickles. Ein normales Szenario ergibt ein Pickle; jede Examples-Zeile eines Scenario Outline ergibt ein eigenes Pickle.

4. Cucumber baut aus den Pickles ausführbare TestCases mit Verweisen auf Hooks und Steps.

5. Globale Hooks laufen vor der Szenariomenge, danach starten szenariobezogene Before-Hooks.

6. Ein Background läuft vor jedem betroffenen Szenario und nach den Before-Hooks.

7. Cucumber sucht für jeden Schritt eine passende Step Definition und führt die Schritte in ihrer notierten Reihenfolge aus.

8. Nach Erfolg, Fehler oder undefiniertem Schritt entstehen Bericht und Aufräumarbeiten durch After-Hooks.

Ein undefinierter, ausstehender oder fehlgeschlagener Schritt überspringt die späteren Schritte des Szenarios (Cucumber API, 2026). Diese Abfolge gehört zu Cucumber. Ein Browser-Treiber, API-Client oder Mobile Driver wird erst aus der Step Definition aufgerufen.

Wie verbinden Step Definitions Text und Code?

Eine Step Definition ist eine Methode mit einem Ausdruck, der auf einen oder mehrere Gherkin-Schritte passt. Cucumber unterstützt dafür genau 2 Ausdrucksformen: Cucumber Expressions und reguläre Ausdrücke (Cucumber, 2026). Variablen aus dem Text werden erfasst, konvertiert und als Methodenargumente übergeben.

Ein fachliches Beispiel für ein Überweisungslimit besteht aus fünf Zeilen:

Die Step Definition für Then enthält den Ausdruck `das verbleibende Tageslimit beträgt {int} CHF`, liest den tatsächlichen Wert über den Systemzugang und vergleicht beide Werte per Assertion. Der Ausdruck erkennt 750 als Zahl und übergibt sie an die Methode. Ein simples `return false` markiert den Schritt nicht als Fehler; die Methode muss eine Assertion oder einen Fehler auslösen (Cucumber, 2026).

Die Schlüsselwörter Given, When und Then beeinflussen das Step-Matching nicht. Zwei Schritte mit identischem Text und unterschiedlichen Schlüsselwörtern gelten für Cucumber als derselbe Ausdruck (Gherkin Reference, 2026). Konsistente, fachlich eindeutige Sätze verhindern mehrdeutige Treffer.

Welche Aufgabe übernimmt Cucumber und welche nicht?

Abbildung 3: Cucumber koordiniert, Treiber greifen zu, Assertions prüfen.

Cucumber koordiniert Szenarien, Steps und Ergebnisse; angebundene Werkzeuge übernehmen Systemzugriff und fachliche Prüfungen. 2 offizielle Leitfäden trennen diese Aufgaben. Einer sagt knapp: „Cucumber is not a browser automation tool“ (Cucumber, 2026). Der andere bestätigt, dass Cucumber keine eigene Assertion-Bibliothek enthält (Cucumber, 2026).

Diese Trennung erlaubt Tests auf mehreren Ebenen. Eine Step Definition kann einen Domain-Service direkt aufrufen, eine API ansprechen oder eine Oberfläche bedienen. Die API-Testautomatisierung erklärt den mittleren Weg. Die Testpyramide hilft bei der Anzahl und Verteilung der Prüfungen.

Wie bleiben Szenarien voneinander isoliert?

Cucumber erzeugt für jedes der ausgeführten Szenarien genau 1 neue Glue-Instanz oder einen neuen World-Kontext, abhängig von der Implementierung. Szenarien sollen keinen Zustand miteinander teilen. Die offizielle Dokumentation verbindet geteilten Zustand mit enger gekoppelten und schwerer wiederverwendbaren Steps (Cucumber, 2026).

Innerhalb eines Szenarios ist geteilter Kontext sinnvoll. Ein Given-Schritt kann ein Konto anlegen, das When und Then danach verwenden. Nach Abschluss muss dieser Zustand verworfen oder kontrolliert bereinigt werden. Statische Variablen, wiederverwendete Browser-Sitzungen und langlebige Testdaten erzeugen Reihenfolgeabhängigkeiten.

Eine isolierte Suite erfüllt vier einfache Bedingungen:

• Jedes Szenario kann allein ausgeführt werden.

• Die Reihenfolge der Szenarien verändert das Ergebnis nicht.

• Testdaten haben klar definierte Eigentümer und Lebensdauer.

• Aufräumcode läuft auch nach einem Fehler.

Fehlschläge werden dadurch leichter zuzuordnen. Ein Szenario verliert weniger Zeit mit Nebenwirkungen früherer Tests, und parallele Ausführung bleibt berechenbarer.

Welche Cucumber-Fehler erhöhen die Wartung?

Abbildung 4: Sechs Checks für wartbare Step Definitions.

Cucumber-Suiten werden wartungsintensiv, wenn Szenariotext technische Bedienung beschreibt oder Step Definitions nach Dateien statt nach Fachdomäne gegliedert sind. Die offizielle Sammlung nennt 2 zentrale Gegenmittel: domänenbezogene Step Definitions und kleine fachliche Aktionen (Cucumber, 2026). Beide Massnahmen senken unnötige Kopplung klar.

• Gherkin enthält Klickpfade, Selektoren, URLs oder Wartezeiten.

• Ein Step verbindet mehrere fachlich getrennte Aktionen.

• Jede Feature-Datei erhält eigene, doppelte Step Definitions.

• Dieselbe Aussage erscheint in vielen leicht veränderten Formulierungen.

• Statischer Zustand koppelt unabhängige Szenarien.

• Ein Step gibt `false` zurück, löst aber keine Assertion aus.

• Cucumber ersetzt fälschlich Unit- oder Komponententests.

• Der Rollout startet ohne Fachseite und gemeinsame Beispielarbeit.

Die Sprache sollte beabsichtigtes Verhalten benennen. Cucumber formuliert dazu: „Your scenarios should describe the intended behaviour of the system, not the implementation“ (Cucumber, 2026). Ein Satz wie „Kunde meldet sich mit gültigen Daten an“ übersteht eine Änderung am Login-Button besser als eine Liste einzelner Klicks.

Wo passt Autemos in einen BDD-Prozess?

Autemos kann vereinbarte Anforderungen oder natürlichsprachliche Testbeschreibungen in visuelle Workflows und ausführbaren Code überführen. Der AI Recorder nennt 3 klar getrennte Eingabearten: Anforderungen, Recordings und natürliche Sprache. Die Codegenerierung nennt Playwright in 2 Sprachen sowie Appium in Java (Autemos, 2026).

Diese Funktionen liegen in der Automationsphase. Discovery, Fachregeln und Freigabe bleiben beim BDD-Team. Auf den geprüften Produktseiten findet sich keine Aussage zu `.feature`-Import, Gherkin-Synchronisation oder Cucumber-Ausführung. Autemos sollte deshalb als prüfbare Workflow- und Codeoption beurteilt werden, nicht als behauptete Cucumber-Laufzeit.

Für ein Projekt sind vier Fragen sinnvoll:

1. Welche fachlichen Beispiele haben echte Leser und Eigentümer?

2. Welche bestehenden Step Definitions oder Playwright-Prüfungen bleiben erhalten?

3. Wo bringt ein visueller Workflow mehr Prüfbarkeit für Fachbeteiligte?

4. Welche Artefakte müssen in Repository, CI/CD und Berichtswesen nachvollziehbar bleiben?

Häufig gestellte Fragen

Die 5 häufigsten Fragen betreffen Browserzugriff, Gherkin, Sprachen, Treiber und Fehlerstatus. Cucumber führt Implementierungen in 4 Pflegekategorien und unterstützt Cucumber Expressions sowie reguläre Ausdrücke als 2 Matching-Formen (Cucumber, 2026). Die Antworten trennen Spezifikation, Runner und technischen Systemzugang fachlich klar voneinander.

Ist Cucumber ein Browser-Testtool?

Cucumber ist kein Browser-Testtool. Es verarbeitet Szenarien und ruft Step Definitions auf. Für Browserzugriffe braucht der Automationscode einen Treiber oder eine Bibliothek wie Selenium oder Playwright (Cucumber, 2026).

Was ist der Unterschied zwischen Cucumber und Gherkin?

Gherkin ist die Grammatik für strukturierte `.feature`-Dateien. Cucumber verarbeitet diese Dateien, ordnet ihre Schritte dem Programmcode zu und meldet Ergebnisse. Beide Begriffe bezeichnen verschiedene Schichten.

Welche Programmiersprachen unterstützt Cucumber?

Die offizielle Übersicht nennt eigene Implementierungen für JavaScript, JVM-Sprachen, Ruby, Scala, Android/Java und C++. Andere Projekte gelten als semi-offiziell, inoffiziell oder nicht mehr gewartet (Cucumber, 2026).

Braucht Cucumber Selenium oder Playwright?

Cucumber braucht Selenium oder Playwright nur für entsprechend implementierte Browserabläufe. Step Definitions können stattdessen APIs, Services, Komponenten oder andere Systemgrenzen ansprechen. Die Wahl folgt dem Verhalten und der Teststrategie.

Warum reicht `return false` nicht für einen Fehler?

Cucumber wertet einen beliebigen Rückgabewert nicht als fehlgeschlagenen Step. Die Step Definition muss eine Assertion oder einen Fehler auslösen. Sonst betrachtet Cucumber die Methode als erfolgreich ausgeführt.

Fazit

Cucumber ist sinnvoll, wenn fachliche Beispiele echte Leser, klare Eigentümer und ausführbare Bedeutung haben. Der technische Weg umfasst 8 Kernstationen von `.feature` bis zum Ergebnis; Gherkin 42.0.1 dokumentiert AST und Pickles (Gherkin Repository, 2026). Browserzugriff und Assertions kommen aus getrennten Bibliotheken.

Halten Sie Szenarien fachlich, Steps klein und Zustand pro Szenario isoliert. Prüfen Sie früh, ob ein Beispiel auf Komponenten-, API- oder UI-Ebene laufen soll. Autemos kann visuelle Workflows und ausführbaren Code aus freigegebenen Beschreibungen erzeugen, ohne belegte native Cucumber-Verbindung. Eine konkrete Zuordnung Ihrer vorhandenen Spezifikationen, Tests und CI/CD-Wege mit klaren Eigentümern und Freigaben klärt ein Gespräch mit dem Autemos-Team.