cucumber
Gurke-Syntax
Suche…
Einführung
Gherkin ist eine für Unternehmen lesbare Sprache für Testautomatisierung und Testdokumentation. Es wird von Gurke verstanden und existiert zusammen als verhaltensgesteuertes Entwicklungswerkzeug.
Syntax
- Feature: Dieses Schlüsselwort gibt an, dass es sich bei der folgenden Beschreibung um eine grundlegende Beschreibung oder den Namen des zu testenden oder dokumentierten Features handelt.
- Hintergrund: Dieses Schlüsselwort kennzeichnet Schritte, die vor jedem Szenario in der Funktion ausgeführt werden.
- Szenario: Dieses Schlüsselwort steht für den Namen oder die grundlegende Beschreibung eines bestimmten Szenarios, das die Funktion testet.
- Szenario-Übersicht: Dieses Schlüsselwort gibt an, dass das Szenario N-mal für jedes Argument ausgeführt wird, das in Beispielen aufgeführt ist, die explizit durch Spaltennamen übergeben werden, die in spitzen Klammern eingeschlossen sind.
- Beispiele: Bei diesem Schlüsselwort wird die Liste der statischen Argumente aufgeführt, die an eine Szenario-Gliederung übergeben werden.
- Gegeben: Dieses Schlüsselwort repräsentiert einen bestimmten Schritt oder eine Voraussetzung, die angenommen wird, bevor Sie fortfahren. Im Arrangement, Act, Assert-Paradigma steht "Arrange" für gegeben.
- When: Dieses Schlüsselwort steht für einen When-Schritt oder das Verhalten, gegen das behauptet werden soll. Im Arrangement, Act, Assert-Paradigma repräsentiert gegebenes "Act".
- Dann: Dieses Schlüsselwort steht für einen Then-Schritt, oder anders ausgedrückt, für den Schritt, in dem das Ergebnis eines Verhaltens validiert wird. Im Arrangement, Act, Assert-Paradigma repräsentiert "Assert".
- Und: Dieses Schlüsselwort wird in Verbindung mit einem der oben genannten Schlüsselwörter verwendet. Wenn Sie zwei gegebene Anweisungen haben, anstatt Given zweimal explizit aufzurufen, können Sie sagen: "A und B".
Die Grundlagen
In diesem Beispiel wird die grundlegende Struktur einer Gurken-Feature-Datei in Gherkin beschrieben. Feature-Dateien verwenden mehrere Schlüsselwörter in der Grundsyntax.
Schauen wir uns die grundlegenden Schlüsselwörter an:
- Feature: Dieses Schlüsselwort gibt an, dass es sich bei der folgenden Beschreibung um eine grundlegende Beschreibung oder den Namen des zu testenden oder dokumentierten Features handelt.
- Szenario: Dieses Schlüsselwort steht für den Namen oder die grundlegende Beschreibung eines bestimmten Szenarios, das die Funktion testet.
- Bei Angabe dieses Schlüsselworts handelt es sich um einen bestimmten Schritt oder eine Voraussetzung, die angenommen wird, bevor Sie fortfahren. Im Arrangement, Act, Assert-Paradigma steht "Arrange" für gegeben.
- Wenn dieses Schlüsselwort einen Wenn-Schritt darstellt oder das Verhalten, gegen das geltend gemacht werden soll. Im Arrangement, Act, Assert-Paradigma repräsentiert gegebenes "Act".
- Dann repräsentiert dieses Schlüsselwort einen dann-Schritt, oder anders ausgedrückt, den Schritt, in dem das Ergebnis eines Verhaltens validiert wird. Im Arrangement, Act, Assert-Paradigma repräsentiert "Assert".
- Und Dieses Schlüsselwort wird oben in Verbindung mit einem der Schlüsselwörter verwendet. Wenn Sie zwei gegebene Anweisungen haben, anstatt Given zweimal explizit aufzurufen, können Sie sagen: "A und B".
- Aber Dieses Schlüsselwort wird in Verbindung gegeben, als und dann um anzuzeigen , dass etwas sollte nicht passieren. Dann A aber nicht B.
Alle Schlüsselwörter müssen sich in einer neuen Zeile befinden und müssen das erste Wort in einer neuen Zeile sein, um vom Gherkin-Parser erkannt zu werden. Die Schlüsselwörter Feature und Scenario müssen unmittelbar danach einen Doppelpunkt haben, wie im folgenden Beispiel dargestellt. Gegeben, Wann, Dann und Und benötigen keinen Doppelpunkt.
Zusätzlich zu den Schlüsselwörtern können Sie Beschreibungen und Kommentare schreiben. Beschreibungen werden nach dem Schlüsselwort aber in derselben Zeile angezeigt, während Kommentare in Zeilen unter den Schlüsselwörtern auftreten. Beim Schreiben von Feature-Kommentaren ist es üblich, explizite Regeln anzugeben, die Kanten und Bedingungen umreißen, die zu unterschiedlichen Ergebnissen des Verhaltens führen.
Feature: Product Login
As a user, I would like to be able to use my credentials to successfully
login.
Rules:
- The user must have a valid username
- The user must have a valid password
- The user must have an active subscription
- User is locked out after 3 invalid attempts
- User will get a generic error message following
login attempt with invalid credentials
Scenario: The user successfully logs in with valid credentials
This scenario tests that a user is able to successfully login
provided they enter a valid username, valid password, and
currently have an active subscription on their account.
Given the user is on the login page
When the user signs in with valid credentials
Then the user should be logged in
Parametrisierte Schritte
Beim Schreiben von Gherkin kann es Zeiten geben, in denen Sie Ihre Schritte für die Wiederverwendbarkeit durch den Ingenieur parametrisieren möchten, der die Testpläne implementiert. Schritte erhalten Parameter über Erfassungsgruppen für reguläre Ausdrücke. ( Technischer Hinweis: Wenn für jede Erfassungsgruppe in Ihrem regulären Ausdruck keine übereinstimmenden Parameter vorhanden sind, können Sie erwarten, dass "CucumberException: Arity Mismatch" ausgelöst wird) als Ganzzahlen als Argumente akzeptieren.
Feature: Product Login
As a user, I would like to be able to use my credentials to successfully
login.
Rules:
- The user must have a valid username
- The user must have a valid password
- The user must have an active subscription
- User is locked out after 3 invalid attempts
- User will get a generic error message following
login attempt with invalid credentials
Scenario: The user successfully logs in with valid credentials
This scenario tests that a user is able to successfully login
provided they enter a valid username, valid password, and
currently have an active subscription on their account.
Given the user is on the login page
When the user signs in with "valid" credentials
Then the user should be logged in
Scenario: The user attempts to log in with invalid credentials
This scenario tests that a user is not able to log in when
they enter invalid credentials
Given the user is on the login page
When the user signs in with "invalid" credentials
Then the user should be logged in
Scenario: The user is locked out after too many failed attempts
This scenario validates that the user is locked out
of their account after failing three consecutive
attempts to log in
Given the user is on the login page
When the user fails to log in 3 times
Then the user should be locked out of their account
Feature-Hintergrund
Wie Sie vielleicht im obigen Beispiel bemerkt haben, schreiben wir denselben Schritt mehrmals:
Given the user is on the login page
Dies kann außerordentlich langwierig sein, insbesondere wenn mehr als ein bestimmter Schritt verwendet wird, der wiederverwendet wird. Gherkin bietet eine Lösung dafür, indem wir uns ein weiteres Stichwort geben, mit dem wir arbeiten können: Background:.
Das Hintergrundschlüsselwort dient dazu, die darunter deklarierten Schritte vor jedem Szenario im Feature auszuführen. Fügen Sie keinen Hintergrundschritt hinzu, es sei denn, Sie sind sich sicher, dass dies für jedes Szenario erforderlich ist. Wie bei den anderen Schlüsselwörtern folgt auf Background eine Beschreibung oder ein Name und es können Kommentare darunter angezeigt werden. Ähnlich wie bei Feature und Szenario muss der Hintergrund mit einem Doppelpunkt fortgesetzt werden.
Feature: Product Login
As a user, I would like to be able to use my credentials to successfully
login.
Rules:
- The user must have a valid username
- The user must have a valid password
- The user must have an active subscription
- User is locked out after 3 invalid attempts
- User will get a generic error message following
login attempt with invalid credentials
Background: The user starts out on the login page
Given the user is on the login page
Scenario: The user successfully logs in with valid credentials
This scenario tests that a user is able to successfully login
provided they enter a valid username, valid password, and
currently have an active subscription on their account.
When the user signs in with "valid" credentials
Then the user should be logged in
Scenario: The user attempts to log in with invalid credentials
This scenario tests that a user is not able to log in when
they enter invalid credentials
When the user signs in with "invalid" credentials
Then the user should be logged in
Scenario: The user is locked out after too many failed attempts
This scenario validates that the user is locked out
of their account after failing three consecutive
attempts to log in
When the user fails to log in 3 times
Then the user should be locked out of their account
Szenario-Gliederung
In einigen Fällen möchten Sie möglicherweise dasselbe Szenario immer wieder ausführen, indem Sie die Argumente ersetzen. In diesem Fall bietet Gherkin mehrere neue Schlüsselwörter für diese Situation an: Szenario-Gliederung: und Beispiel:. Das Schlüsselwort Szenario-Gliederung teilt Cucumber mit, dass das Szenario mehrmals ausgeführt wird, um Argumente aus einer Liste zu ersetzen. Das Schlüsselwort Examples wird aufgerufen, bevor die Liste explizit notiert wird. Argumente für Szenario-Konturen sollten in spitzen Klammern stehen. Beachten Sie im nachstehenden Beispiel, dass die in eckigen Klammern eingeschlossenen Argumentnamen den unter Beispielen aufgeführten Spaltennamen entsprechen. Jede Spalte ist durch vertikale Striche getrennt, wobei die Spaltennamen in der ersten Zeile stehen.
Feature: Product Login
As a user, I would like to be able to use my credentials to successfully
login.
Rules:
- The user must have a valid username
- The user must have a valid password
- The user must have an active subscription
- User is locked out after 3 invalid attempts
- User will get a generic error message following
login attempt with invalid credentials
Background: The user starts out on the login page
Given the user is on the login page
Scenario Outline: The user successfully logs in with their account
This scenario outlines tests in which various users attempt
to sign in successfully
When the user enters their <username>
And the user enters their <password>
Then the user should be successfully logged on
Examples:
| username | password |
| frank | 1234 |
| jack | 4321 |
Stichworte
Zu Dokumentationszwecken möchten Sie möglicherweise Testpläne oder Szenarien nach Kategorien filtern. Entwickler möchten möglicherweise Tests ausführen, die auf denselben Kategorien basieren. Mit Gherkin können Sie Features sowie einzelne Szenarien über den Benutzer von Tags kategorisieren. Beachten Sie im Beispiel unten, dass das Schlüsselwort Feature das Tag "@Automation" ist. Gurke erkennt dies als Tag vom Benutzer des Symbols "@". In diesem Beispiel möchte der Ingenieur klarstellen, dass diese Tests für die Automatisierung verwendet werden, wobei nicht jeder Test automatisierbar ist. Einige Tests müssen von Hand durchgeführt werden.
Beachten Sie auch, dass das Tag @Production zum Szenario-Testbenutzer gesperrt wurde. In diesem Beispiel ist dies darauf zurückzuführen, dass dieses Szenario nur in der Produktionsumgebung der Anwendung aktiv ist. Die Entwickler möchten nicht, dass ihre Sandbox-Konten während der Entwicklung gesperrt werden. Mit diesen Tags können sie erzwingen, dass dieser Test nur in der Produktionsumgebung ausgeführt wird.
Schließlich hat die Szenario-Gliederung das Tag @Staging. In diesem Beispiel liegt dies daran, dass die Konten Staging-Konten sind und in den anderen Umgebungen nicht funktionieren. Wie beim @Production-Tag wird sichergestellt, dass diese Tests nur in der Staging-Umgebung ausgeführt werden.
Dies sind nur einige Beispiele dafür, wo, wie und warum Sie Tags verwenden. Letztendlich werden diese Tags für Sie und die Entwickler eine Bedeutung haben und können alles sein, um sie zu kategorisieren, wie Sie es für richtig halten.
@Automation
Feature: Product Login
As a user, I would like to be able to use my credentials to successfully
login.
Rules:
- The user must have a valid username
- The user must have a valid password
- The user must have an active subscription
- User is locked out after 3 invalid attempts
- User will get a generic error message following
login attempt with invalid credentials
Background: The user starts out on the login page
Given the user is on the login page
Scenario: The user successfully logs in with valid credentials
This scenario tests that a user is able to successfully login
provided they enter a valid username, valid password, and
currently have an active subscription on their account.
When the user signs in with "valid" credentials
Then the user should be logged in
Scenario: The user attempts to log in with invalid credentials
This scenario tests that a user is not able to log in when
they enter invalid credentials
When the user signs in with "invalid" credentials
Then the user should be logged in
@Production
Scenario: The user is locked out after too many failed attempts
This scenario validates that the user is locked out
of their account after failing three consecutive
attempts to log in
When the fails to log in 3 times
Then the user should be locked out of their account
@Staging
Scenario Outline: The user successfully logs in with their account
This scenario outlines tests in which various users attempt
to sign in successfully
When the user enters their <username>
And the user enters their <password>
Then the user should be successfully logged on
Examples:
| username | password |
| frank | 1234 |
| jack | 4321 |
Gurken-Tipps
- Jedes Szenario testet ein Verhalten
- Szenarien werden deklarativ geschrieben
- Vermeiden Sie zufällige Details innerhalb des Szenarios
- Lassen Sie das Offensichtliche weg
- Vermeiden Sie konjunktive Schritte
- Halten Sie Ihre Szenarien kurz
- Sie müssen nicht viele Szenarien in derselben Funktion haben
- Verwenden Sie beschreibende Szenarionamen
- Habe nur einen Wannschritt
- Verwenden Sie das "sollte" in den Then-Schritten