Loading content
Cucumber ist ein BDD-Testwerkzeug, das ausführbare Spezifikationen mittels Gherkin-Feature-Dateien unterstützt. Es fördert die Zusammenarbeit zwischen technischen und fachlichen Beteiligten, indem natürliche Sprachszenarien in automatisierte Tests überführt werden. Cucumber lässt sich in viele Programmiersprachen und CI-Systeme integrieren, um Verhalten entl…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und verwandte Bausteine zu öffnen.
Technischer Baustein: kann automatisiert, integriert oder betrieben werden.
Konkretes Rädchen im System, das in größeren Zusammenhängen wirkt.
Cucumber ist ein BDD-Testwerkzeug, das Gherkin-Feature-Dateien als ausführbare Spezifikationen ausführt und so fachliche Beispiele gegen den Code prüft.
Cucumber wurde von Aslak Hellesøy im Ruby-Umfeld gestartet, um lesbare Geschäftsszenarien als ausführbare Akzeptanztests zu formulieren. Die verfügbaren Quellen nennen es zunächst als Ergänzung zu RSpec; später kamen Implementierungen für weitere Sprachen hinzu. Der Kern blieb gleich: Gherkin verbindet Fachsprache mit automatisierter Verifikation.
Eine Cucumber-Prüfung läuft wie eine Übersetzungskette: In der `.feature`-Datei beschreibt Gherkin ein Feature mit Szenarien und Schritten. Cucumber liest diese Zeilen, ordnet jeden Schritt einer Step Definition zu und führt den hinterlegten Code aus. Am Ende entsteht pro Szenario ein klares Pass/Fail-Signal samt Bericht; fehlt eine passende Zuordnung, bleibt der Schritt unbehandelt.
Eine Arbeitsweise, bei der Beispiele und Zusammenarbeit Anforderungen präziser und überprüfbarer machen.
Die lesbare Sprachform in `.feature`-Dateien mit festen Schlüsselwörtern und klarer Struktur.
Ein konkreter Ablauf aus Vorbedingungen, Handlung und erwarteter Wirkung.
Codebausteine, die Textschritte mit Programmlogik verknüpfen.
Dasselbe Artefakt dient als Dokumentation und als automatisierbarer Test.
Cucumber ist nützlich, wenn Fachseite und Entwicklung denselben Wortlaut für Akzeptanzkriterien brauchen, etwa vor Releases, für Regressionstests oder als laufend aktualisierte Dokumentation in CI. Es passt besonders gut zu stabilen, gut formulierbaren Verhaltensregeln. Bei vielen Ausnahmen, unklaren Formulierungen oder stark UI-getriebenen Details steigen Pflegeaufwand, Kopplung und Fehlinterpretationsrisiko.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.