{Es gibt nicht viele Dienste, die den Ruf von Cypress genießen, und ich habe immer gewusst, dass es nicht nur Gerede ist. Obwohl das Schreiben von Tests mit Cypress jedes Mal ein Vergnügen war, hatte ich das Gefühl, dass es zu hoch für mich ist, Cypress in eine echte CI/CD-Pipeline einzubinden. Nun bin ich froh, berichten zu können, dass diese Annahme genau das war - eine Annahme, eine falsche noch dazu. GitHub Actions ermöglicht den Aufbau einer E2E-Testing-Pipeline zum Nulltarif*: nor time, nor financial.

In den nächsten Abschnitten werden wir dank der wunderbaren Kombination von Cypress und GitHub Actions ein einfaches CI/CD einrichten, das in der Lage sein wird, unsere E2E-Tests auf verschiedenen Geräten und Betriebssystemen auszuführen, Anfragen auf ihrem Weg zur API abzufangen und ein Video der tatsächlichen Interaktionen zurückzugeben, wenn der Testlauf fehlgeschlagen ist.

Agenda

1. Einrichten einer einfachen Next.js application

2. Creating an endpoint in Next.js

3. Adding Cypress and writing a test

4. Integrating Cypress into GitHub

5. Running Cypress via GitHub Actions

Useful links

• Cypress

• GitHub Actions

• Next.js Documentation

• 💻 Code (GitHub)

1. Einrichten einer einfachen Next.js-Anwendung

Für diesen Artikel habe ich eine einfache Next.js-Anwendung erstellt, die ein Formular mit asynchroner Logik enthält. Ich habe Next.js aus reiner Bequemlichkeit gewählt, denn Cypress ist völlig unabhängig von der verwendeten Front-End-Technologie und kann für die Durchführung von Tests auf jeder bestehenden Website eingesetzt werden. Wie auch immer, unser Hauptaugenmerk liegt auf der Datei Form.js, die wie folgt aussieht:

Der Anwendungsfall ist sehr einfach: Der Benutzer füllt alle Felder aus, klickt auf "Submit", wartet auf die Antwort von einem recht langsamen Server und erfreut sich an einer großen hässlichen Überschrift "Erfolg!".

2. Erstellen eines Endpunkts in Next.js

Um einem realen Szenario möglichst nahe zu kommen, werden wir unsere Anfrage nicht wie Wilde nachahmen, sondern eine native Next.js-Funktion namens API Routes, um einen tatsächlichen (wenn auch sehr einfachen) Endpunkt zu erstellen:

Alles, was dieser Endpunkt tut, ist den Status 200 zurückzugeben, nachdem wir 3 Sekunden unseres Lebens verschwendet haben. Zum Glück ist das alles, was wir brauchen, um mit dem Testen unserer Anwendung zu beginnen.

3. Hinzufügen von Cypress und Schreiben eines Tests

Nun wird es spannend. Wir fügen eine Abhängigkeit hinzu, die ein absoluter Star der heutigen's Show ist: Cypress.

Die Macher von Cypress nennen es "ein Front-End-Testing-Tool der nächsten Generation, das für moderneend testing tool built for the modern web", aber ich würde es eher als "das einzige Tool bezeichnen, das Sie jemals für das Testen begeistern kann 😎". E2E-Tests sind per Definition viel näher an der Simulation der tatsächlichen Benutzererfahrung und daher viel angenehmer zu schreiben (weil man nicht in die Implementierungsdetails eintaucht), aber Cypress hebt es auf eine andere Ebene.

Cypress hat exzellente Dokumentationmit tonnenweise Beispielen, von denen ich Ihnen besonders einen Blick auf das sogenannte Kitchen Sink, weil es so ziemlich jedes Szenario enthält, das Ihnen in Ihrer Anwendung begegnen könnte. Leider wird sich der heutige Artikel nicht unbedingt auf die Leistungsfähigkeit von Cypress in Bezug auf das Schreiben von Assertions und die Simulation von Benutzerinteraktionen konzentrieren, sondern eher auf die Einfachheit, alles in einer Konfiguration einzurichten, die in produktionsreifen Anwendungen nützlich sein kann.

Das erste Mal, wenn Sie Cypress durch yarn/npm run cypress open starten, wird es eine grundlegende Ordnerstruktur mit einer Reihe von Dateien generieren und ich schlage vor, dass Sie diese nicht sofort durchstreichen, da z.e., die Beispiele, die in cypress/integration/examples zur Verfügung gestellt werden, können sehr nützlich sein.

Cypress kommt mit einer sehr praktischen GUI, mit der wir alle unsere Tests durchsuchen und verwalten können.

Sie wird ihren Wert beweisen, wenn wir endlich unseren ersten Test schreiben:

Lassen Sie uns aufschlüsseln, was'hier vor sich geht:

Ich wollte diese explizite Unterscheidung zwischen "Befehlen" und "Assertionen" machen (genauso wie Cypress documentation), um zu verdeutlichen, was die Hauptintuition hinter dem Schreiben von Cypress-Tests (und eigentlich jedem anderen UI-Test) ist: zuerst wählen wir ein Element aus und dann führen wir entweder eine Aktion darauf aus oder wir prüfen, ob es bestimmte Bedingungen erfüllt.

Was{ENTITY_315}} in diesem Beispiel wirklich hervorzuheben ist, ist die letzte Zeile:

Beachten Sie, dass ich 'nicht angeben musste, welche Art von Inhalt Cypress erwarten soll, ich habe es nur darüber informiert, dass es den String "Erfolg!". Die Leute hinter Cypress sind sich dessen bewusst, was für die meisten von uns lästiges Testen ist, also können Sie eine Menge KISSes of encouragement from them.

Sofort sollte unser Test in der Cypress GUI landen. Let's run it there:

Wenn Sie Glück haben, sollten Sie folgendes sehen:

In der linken Spalte gibt Cypress eine Übersicht über alle Aktionen, die es für uns durchgeführt hat. Wir sehen auch das Ergebnis unserer Behauptung, das - und ich hoffe, dass Sie das oft sehen werden - in diesem Fall ein Erfolg ist.

In diesem einfachen Test haben wir unbewusst eine bestimmte E2E-Testdesignentscheidung getroffen, die Cypress an entire article to: haben wir beschlossen, eine Anfrage an einen tatsächlichen Endpunkt zu senden. Jedes Mal, wenn die Ergebnisse unserer Tests die Datenbank erreichen, müssen wir eine ganz neue Schicht pflegen. Bereinigen wir die Datenbank, nachdem wir die Tests ausgeführt haben? Tun wir das in der Produktion? Oder richten wir eine spezielle Staging-Umgebung für sie ein? 🤯

auf der anderen Seite: das ist so realistisch wie es nur geht, das ist genau die Erfahrung, die der Benutzer erwarten kann, was die Motivation hinter E2E-Tests ist. Wir müssen uns nicht um das Mocking der Serverantworten kümmern (die sich im Laufe der Zeit auch ändern können), aber neben der Überwachung der Daten müssen wir auch die Zeit beachten, die für die Beendigung der Anfrage benötigt wird. Wie wir alle wissen, lautet das älteste Sprichwort der Welt "Zeit ist Geld", also nehme ich an, dass wir in der Lage sein wollen, dies in unseren Tests zu berücksichtigen.{Glücklicherweise stellt uns Cypress eine Methode namens intercept zur Verfügung, die genau das tut - sie fängt die Anfragen ab, die wir zu senden versuchen und gibt eine Antwort zurück, die wir in unserem Test angeben. Mit anderen Worten, es ermöglicht uns, Netzwerkanfragen nachzustellen. Mit dieser bescheidenen Ergänzung...

...können wir erwarten, dass unser Test etwas weniger Zeit benötigt:

4. Integration von Cypress in GitHub

Nun, da wir unseren ersten Test haben, ist es'an der Zeit, ihn von unserer lokalen Umgebung in ein tatsächliches CI/CD zu übertragen. Dies beginnt mit der Integration von Cypress in unser Repository, was durch einen Dienst namens Cypress Dashboard ermöglicht wird. Der gesamte Prozess ist in der Cypress-Dokumentation perfekt beschrieben.

Wenn wir autorisiert sind, müssen wir unser Projekt initialisieren:

Den Anweisungen von Cypress Dashboard folgend, fügen wir den projectId zu cypress.json, die Cypress bei seinem ersten Lauf für uns hätte erstellen sollen. Der gesamte Prozess sollte, wenn er korrekt ausgeführt wird, dazu führen, dass die Cypress-Integration im Abschnitt GitHub "Integrations" in den Repository-Einstellungen vorhanden ist.

Hier beginnt der letzte und lustigste Teil.

5. Ausführen von Cypress über GitHub Actions

GitHub Actions ist eine großartige Automatisierungspipeline, mit der wir unsere Cypress-Testsuite für jeden Pull Request in unserem Repository ausführen werden. Dazu stellen wir ihr eine .yml-Datei zur Verfügung, die alle Anweisungen enthält, die für die Ausführung unserer Tests benötigt werden:

{

Eben noch waren Sie kurz davor zu kündigen, weil Sie nie vorhatten, Dev-ops zu werden, richtig? Diese Befürchtung hat mich viel zu lange davon abgehalten, Cypress in einer kommerziellen Umgebung einzusetzen. Doch mit Hilfe von GitHub Actions und Cypress (und deren vordefinierten Routinen namens cypress-io/github-action), ließ mir die Kinnlade herunterfallen, als ich sie das erste Mal in Aktion sah:

You thought that was cool? Wie würdest du dann das Hinzufügen einer Aufzeichnung unserer Tests mit nur 4 Zeilen Konfiguration nennen?

The possibilites don't end here. Mit dem Cypress-Plugin für GitHub Actions können Sie alle möglichen verrückten Dinge tun, wie zum Beispiel: specyfing different browsers, die durchzuführenden Tests einzugrenzen oder tests parallelization. Kombinieren Sie dies mit der Kenntnis von GitHub Actions events und Sie können sich einen maßgeschneiderten E2E-Test-Workflow zusammenstellen.

Aaaaand that's a wrap! Wenn Ihnen das nicht Lust macht, Tests zu schreiben, gibt es keine Hoffnung für Sie 💀.