End-to-End-Prüfung mit Cucumber und Gherkin

In ihrem letzten Projekt haben unsere Softwareentwickler Pau Sánchez und Carlos Rodriguez an automatisierten End-to-End-Tests für Flowers Software gearbeitet. Auf innovative Weise.

Die Art und Weise, wie sie die Umgebung für diese End-to-End-Tests eingerichtet haben, schafft eine neue Form der Verbesserung der bekannten End-to-End-Tests. Zunächst werden Pau und Carlos die verschiedenen Teile erläutern, die die Grundlage für diese Art der Implementierung bilden, und anschließend werden sie sich damit befassen, wie dies im Gesamtkontext funktioniert.

Cucumber ist eines der beliebtesten Tools für die verhaltensorientierte Entwicklung (BDD) in der Softwareentwicklung, da es Entwicklern ermöglicht, das Verhalten eines Systems in einer natürlichen Sprache auszudrücken. Dies erleichtert das Verständnis für nicht-technische Stakeholder. Diese Sprache wird Gherkin genannt. Ein gutes Beispiel hierfür wäre:

Feature: Suche nach einem Produkt

Als Benutzer

möchte ich nach einem Produkt suchen

damit ich das gesuchte Produkt finden kann

Szenario: Erfolgreiche Suche

Angenommen, ich bin auf der Startseite

Wenn ich nach „Gurke“ suche

Dann sollte ich eine Liste mit Produkten sehen, die mit „Gurke“ zu tun haben

Hier definieren wir einen Testfall, um die erfolgreiche Suche nach einem Produkt auf einer bestimmten Website zu überprüfen. Wie gezeigt, ist die Lesbarkeit eines in Gherkin geschriebenen Testfalls im Vergleich zu jeder gängigen Cypress-Programmiersprache erheblich verbessert. Das liegt daran, dass er auf natürliche Weise geschrieben ist und somit jeder verstehen kann, was in diesem Fall passieren soll.

Cypress ist ein End-to-End-Testframework, das häufig in Verbindung mit Cucumber zum Testen des Verhaltens von Webanwendungen verwendet wird. Jeder, der mit End-to-End-Tests von Webanwendungen vertraut ist, kennt Cypress und seine großartigen Fähigkeiten. Es ist auch für seine hervorragende Lesbarkeit des Testcodes bekannt, aber wir gehen noch einen Schritt weiter.

Die Integration, von der wir sprechen, ist **@badeball/Cypress-cucumber-preprocessor (**https://github.com/badeball/cypress-cucumber-preprocessor**)**, ein Tool, mit dem Entwickler die natürliche Sprachsyntax von Cucumber zum Schreiben von Cypress-Tests verwenden können. Es kann über npm installiert werden und funktioniert sowohl für TypeScript- als auch für JavaScript-basierte Cypress-Umgebungen.

Um den Präprozessor zu verwenden, müssen Sie für jeden Testbatch eine „*.feature“-Datei erstellen. Diese sollte eine Beschreibung des zu testenden Verhaltens enthalten, geschrieben in der Gherkin-Syntax von Cucumber, wie in Abb. 1.1 gezeigt. Damit werden die Schritte definiert, die zum Testen des gegebenen Szenarios erforderlich sind.

Als Nächstes sollte das Verhalten in einer „*.steps.js“-Datei definiert werden. Diese Datei muss die Bibliothek integrieren und jeden Schritt einzeln definieren, wodurch das Cypress-Verhalten für jede der Phrasen festgelegt wird. Für die im obigen Beispiel gezeigte „.feature“-Datei würde ein Beispiel für die Implementierung wie folgt aussehen:

import { Given, When, Then } from ‚cypress-cucumber-preprocessor/steps‘;
Given(‚Ich bin auf der Startseite‘, () => {
  cy.visit(‚http://localhost:3000‘);
});
When(‚Ich suche nach {string}‘, (searchTerm) => {  cy.get(‚input[name=„search“]‘).type(searchTerm);
  cy.get(‚button[type=„submit“]‘).click();
Dann(‚Ich sollte eine Liste mit Produkten sehen, die mit {string} in Verbindung stehen‘, (searchTerm) => {
cy.get(‚.product-list‘).should(‚contain‘, searchTerm);
});

Jetzt können wir die .feature in Abb. 1.1 ausführen, da wir die natürliche Sprache mit etwas verknüpft haben, das Cypress ausführen kann. Beachten Sie, dass die zweite und dritte Definition sogar ein Eingabefeld haben, in dem Variablen in der natürlichen Sprache definiert werden können, wodurch dieser Test einfacher erweitert werden kann. Wir werden dies im nächsten Absatz untersuchen.

Wir wissen nun, welche Tools verwendet werden und wie diese kombiniert werden. Kommen wir nun zum Kern der Sache und sehen uns einige Beispiele an, wie dies nützlich sein kann und welche zusätzlichen Funktionen die Entwicklung von Testautomatisierungen noch einfacher machen.

Nehmen wir an, wir überprüfen die Feldüberprüfung auf einer Registrierungsseite und möchten jeden Ablehnungsfall für dieses bestimmte Formular überprüfen. Wir könnten einen Test schreiben, der wie folgt aussehen könnte:

Funktion: Registrierungsformular

Hintergrund:

Angenommen, ich gehe auf die Hauptseite

Und ich klicke auf „Registrieren“

Dann sollte ich auf der Registrierungsseite sein

Szenario: Feldakzeptanz überprüfen

Angenommen, ich bin auf der Registrierungsseite

Wenn ich „<Eingabe>“ in das Feld „<Feldname>“ eingebe

Dann sollte ich die Fehlermeldung „<Fehlermeldung>“ sehen

Beispiel:

| Eingabe | Feldname | Fehlermeldung |

| 12345 | Passwort | Dies ist eines der 10 häufigsten Passwörter |

| N4m3 | Benutzername | Benutzername darf keine Zahlen enthalten |

…

Zunächst verwenden wir die Funktion „Hintergrund“, die die darin definierten Schritte ausführt, bevor jedes Szenario ausgeführt wird. Hintergrundszenarien definieren einen bestimmten Kontext, der beim Testen der angegebenen Seite relevant ist, da dies bei der Entwicklung von End-to-End-Tests in Cypress als bewährte Vorgehensweise gilt.

Zweitens gibt es das Feld „Beispiel“, das die Ausführung wiederkehrender Tests erleichtert, indem es die Definition verschiedener Eingaben ermöglicht.

Jede Zeile steht für eine andere Testausführung mit denselben Schritten, aber unterschiedlichen Inhalten und erwarteten Ergebnissen. Da zur Erweiterung der Testabdeckung lediglich Zeilen zu den Beispielen hinzugefügt werden müssen, lassen sich Tests sehr einfach erweitern.

Dies ermöglicht auch ein modulares Verhalten in den Methoden, da der Test letztendlich in der Datei „*.feature“ definiert ist, sodass wir auf unseren Seiten Methoden verwenden können, die es ermöglichen, je nach Eingabe unterschiedliche Verhaltensweisen zu nutzen. Normalerweise wird dies beim Testen als schlechte Praxis angesehen, da die Zulassung unterschiedlicher Routen für einen Test oft den Zweck des Tests zunichte macht. Wenn dies jedoch nur verwendet wird, um Schritte in Cucumber zu erstellen, die flexibler und lesbarer sind, können wir den Gesamtaufwand für die Codierung reduzieren.

Das Format für den „Beispiel“-Satz kann auch als Parameter für einen Give/When/Then/And-Satz verwendet werden. Für das vorherige Beispiel könnten wir dies wie folgt schreiben:

Feature: Registrierungsformular

Hintergrund:

Angenommen, ich gehe auf die Hauptseite

Und ich klicke auf „Registrieren“

Dann sollte ich auf der Registrierungsseite sein

Szenario: Feldakzeptanz überprüfen

Angenommen, ich bin auf der Registrierungsseite

Wenn ich in das Registrierungsformular

| Eingabe | Feldname |

| 12345 | Passwort |

| 123456 | Passwortprüfung |

Dann sollte die Fehlermeldung „Passwörter stimmen nicht überein“ angezeigt werden

Damit dies funktioniert, müssten wir die Parameter zum Schritt „Ich gebe das Registrierungsformular ein“ in der Datei „*.steps.js“ hinzufügen, etwa wie folgt:

import { Given, When, Then, DataTable } from ‚cypress-cucumber-preprocessor/steps‘;

…

When(‚Ich gebe das Registrierungsformular ein‘, (datatable) => {

datatable.hashes().forEach((element) => {

cy.get(‚[data-cy=‘+ element.FieldName + ‚]‘).type(element.Input);

})

});

…

Wie gezeigt, ermöglicht uns die DataTable, Arrays direkt aus dem Cucumber-Code zu erhalten, sodass Code, der sonst immer wieder wiederholt werden müsste, auf sehr einfache und lesbare Weise in Zeilen einer Tabelle ausgefüllt werden kann. Dies ermöglicht unterschiedliche Verhaltensweisen basierend auf den gegebenen Parametern, während gleichzeitig die bewährten Praktiken beibehalten werden, da die „echten“ Testverfahren aus den Cucumber-Definitionen stammen.

Zusammenfassend lässt sich sagen, dass Cypress-cucumber-preprocessor ein nützliches Paket ist, mit dem Entwickler die natürliche Sprachsyntax von Cucumber zum Schreiben von Cypress-Tests verwenden können. Dies erleichtert nicht-technischen Stakeholdern das Verständnis des Verhaltens eines Systems und reduziert gleichzeitig den Entwicklungsaufwand.