Implementierung von Cucumber-Szenario-Umrissen in BDD-Frameworks
Verhaltensgetriebene Entwicklung (BDD) ist eine agile Softwareentwicklungspraxis, die die Zusammenarbeit zwischen Stakeholdern und Entwicklern verbessert, indem sie eine einfache, domänenspezifische Sprache verwendet, um das Systemverhalten zu beschreiben.
Eines der mächtigsten Werkzeuge im BDD ist Cucumber, das zum Schreiben klarer Spezifikationen verwendet wird. Es kann auch zum Testen mit den am häufigsten verwendeten Programmiersprachen wie Java, Python oder C# eingesetzt werden und lässt sich mit UI-Frameworks wie Selenium integrieren oder für API-Tests verwenden.
Szenarien-Vorlagen sind Teil der Gherkin-Syntax von Cucumber, die zum Schreiben ausführbarer Spezifikationen verwendet wird. Im Gegensatz zu regulären Szenarien, die ein einzelnes konkretes Beispiel definieren, ermöglichen Szenarien-Vorlagen die Angabe mehrerer Beispiele in tabellarischer Form.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Unterschiede zwischen Szenario und Szenarien-Vorlage
Szenarien in Cucumber stellen einen Testfall in der Grundform von Gegeben-Wenn-Dann dar. Die Gherkin-Sprache erlaubt es, diese Testszenarien in einfachem Deutsch (und anderen Sprachen) zu formulieren, sodass sie von allen, selbst nicht-technischen Personen, verstanden und geschrieben werden können. Die Step-Definitionen, welche die Implementierung der Schritte darstellen, werden in separaten Dateien angelegt.
Für manche Funktionalitäten ist es sinnvoll, dasselbe Szenario mit unterschiedlichen Testdaten zu wiederholen – dies ist wahrscheinlich als datengetriebenes Testen bekannt. In Cucumber wird dies durch die Verwendung der Szenarien-Vorlage mit einer Beispieltabelle gelöst, die die zu verwendenden Datensätze enthält. Jedes Beispiel wird dabei als separater Test gezählt.
Cucumber Szenarien-Vorlage Syntax
Ein typisches Cucumber-Projekt enthält Feature-Dateien, in denen die Cucumber-Tests definiert sind, und Step-Definitions-Dateien mit den Implementierungen der Schritte.
Eine Feature-Datei sollte eine Anforderungsspezifikation und die zu deren Überprüfung verwendeten Szenarien repräsentieren. Die Basissyntax für ein einfaches Cucumber-Szenario sieht so aus:
Szenario: Ungültiger Login
Gegeben sei, dass ich zur Login-Seite navigiere
Wenn ich ungültige Zugangsdaten eingebe
Dann erhalte ich eine Fehlermeldung
Das Szenario kann auch Variablen enthalten, die in der Step-Definition entsprechend behandelt werden.
Szenario: Ungültiger Login
Gegeben sei, dass ich zur Login-Seite navigiere
Wenn ich den Benutzernamen test und das Passwort invalid eingebe
Dann erhalte ich eine Fehlermeldung: "Invalid login".
Die Werte „test“, „invalid“ und „Invalid login“ werden als Variablen behandelt. Schauen wir nun, was passiert, wenn wir verschiedene Kombinationen der bereitgestellten Variablen ausprobieren wollen – wir könnten mehrere Szenarien anlegen, die sich nur durch die Variablenwerte unterscheiden, oder die Szenarien-Vorlage verwenden, mit der wir eine Tabelle mit den unterschiedlichen Datenkombinationen erstellen können:
Dann erhalte ich eine Fehlermeldung: "<Fehlermeldung>".
Beispiele:
| benutzername | passwort | fehlermeldung |
| test | invalid | Invalid login |
| test | | Bitte Passwort eingeben |
| | invalid | Bitte Benutzernamen eingeben |
Die Datenkombinationen werden unter dem Schlüsselwort „Beispiele“ in einer Tabelle festgehalten. Die Kopfzeilen der Tabelle definieren die Variablennamen, jede weitere Zeile enthält die Datenkombination. Jedes Beispiel innerhalb eines Cucumber-Features wird als eigener Testfall behandelt.
Beispieltabelle vs. Datentabellen
Beispiel- und Datentabellen sehen zwar ähnlich aus, erfüllen jedoch unterschiedliche Aufgaben. Der Hauptunterschied besteht darin, dass Beispiele zur Umsetzung datengetriebener Szenarien verwendet werden, während Datentabellen dann eingesetzt werden, wenn die Szenarien-Schritte mit mehreren Variablen arbeiten müssen.
Eine Datentabelle kann folgendermaßen genutzt werden:
Szenario: Ungültiger Login
Gegeben sei, dass ich zur Login-Seite navigiere
Wenn ich die Zugangsdaten eingebe
| benutzername | passwort |
| test | invalid |
Dann erhalte ich eine Fehlermeldung: "Invalid login".
oder so:
Szenario: Ungültige Anmeldung
Angenommen, ich navigiere zur Anmeldeseite
Wenn ich die Zugangsdaten eingebe
| Benutzername | test |
| Passwort | ungültig |
Dann erhalte ich eine Fehlermeldung: "Ungültige Anmeldung".
Daten-Tabellen sind besonders nützlich, wenn die Schritte mehrere Variablen erfordern, und sie sind leichter lesbar, als wenn jeder Wert in den Schritt integriert wird.
Arbeiten mit Datentabellen und Szenario-Umrissen
Datentabellen und Szenario-Umrisse können auch zusammen verwendet werden. Der Name der Variablen wird in der Datentabelle angegeben und dann in der Beispieltabelle wiederverwendet.
Szenario-Umriss: Ungültige Anmeldung
Angenommen, ich navigiere zur Anmeldeseite
Wenn ich die Zugangsdaten eingebe
| Benutzername | <Benutzername> |
| Passwort | <Passwort> |
Dann erhalte ich eine Fehlermeldung: "<Fehlermeldung>".
Beispiele:
| Benutzername | Passwort | Fehlermeldung |
| test | ungültig | Ungültige Anmeldung |
| test | | Bitte Passwort eingeben |
| | ungültig | Bitte Benutzernamen eingeben |
Vorteile der Verwendung von Szenario-Umrissen
Szenario-Umrisse können als „Vorlage“ für einen Testfall interpretiert werden. Was sie tatsächlich tun, sobald sie in ein Testautomatisierungs-Framework implementiert sind, ist, dass das gleiche Szenario mit unterschiedlichen Datensätzen ausgeführt wird.
Der Vorteil besteht darin, dass es weniger Gherkin-Zeilen gibt und Wiederholungen reduziert werden. Das bedeutet: Wenn eine Änderung im gemeinsamen Szenario notwendig ist, muss sie nur einmal angepasst werden – und wird danach auf alle Datenkombinationen angewendet.
Ein weiterer Vorteil von Szenario-Umrissen ist, dass sie mit minimalem Aufwand eine größere Abdeckung bieten können. Um einen neuen Testfall hinzuzufügen, muss lediglich eine neue Beispielzeile hinzugefügt werden.
Best Practices für das Schreiben von Szenario-Umrissen
- Verwenden Sie echte Daten: Das Team übersieht mit geringerer Wahrscheinlichkeit Randfälle oder verborgene Informationen, wenn es echte Anwendungsfälle nutzt, um Verhaltensweisen nachzuvollziehen.
- Kommunizieren Sie das Ziel in der Sprache des Geschäfts, um das gegenseitige Verstehen zwischen nicht-technischen und technischen Stakeholdern zu verbessern.
- Erklären Sie Ihre Absicht, statt wie es umgesetzt wird; die Schritt-Beschreibungen sollten möglichst wenig technisch sein. Der Fokus sollte stärker auf den Funktionen des Systems als auf seiner Funktionsweise liegen.
- Nur das Notwendige aufnehmen: Um das Szenario für alle Beteiligten interessant zu halten, vermeiden Sie überflüssige Schritte.
Fazit
Förderung der Zusammenarbeit: BDD fördert die Zusammenarbeit zwischen Stakeholdern und Entwicklern.
Einfache Sprache: BDD verwendet eine einfache, domänenspezifische Sprache zur Beschreibung des Systemverhaltens.
Agile Praxis: BDD ist eine Praxis innerhalb der agilen Softwareentwicklung.
Stakeholder-Beteiligung: BDD bezieht Stakeholder in die Definition des Systemverhaltens mit ein.
Beschreibung des Systemverhaltens: BDD konzentriert sich darauf, das Systemverhalten effektiv zu beschreiben.
Cucumber ist ein hervorragendes Kollaborationswerkzeug zwischen Nicht-Technikern, Entwicklern und Testern. Es ist ein BDD-Tool, das schriftliche Spezifikationen bereitstellt und im Test eingesetzt werden kann. Mehrere Szenarien können geschrieben werden, um verschiedene Anforderungen aufzuzeigen.
Es ist sinnvoll, einen Szenario-Umriss mit unterschiedlichen Wertekombinationen in der Beispiele-Tabelle zu nutzen, wenn Szenarien die gleichen Schritte haben, aber verschiedene Datenwerte als Eingaben oder Ausgaben benötigen.
Abonnieren Sie den Newsletter des CTO Club für weitere Einblicke.
