Cypress: Fordern Sie Ihre schnelle Feedbackschleife heraus

Wir schreiben das Jahr 2023. Wir leben jetzt in einer Welt des KI-Chats, der KI-Bildkomposition und anderer einflussreicher Technologien. Die Welt bewegt sich immer schneller und schneller. Und irgendwie haben wir als Testingenieure oder Entwickler eine Rolle zu spielen, die oft damit zu tun hat, unseren Kunden Software zu liefern, auf die sie sich verlassen können. So einfach ist das und deshalb bringen wir Ihnen neue Erkenntnisse, um Ihre schnelle Feedbackschleife regelmäßig herauszufordern.

Damit wir uns auf die von uns entwickelte Software verlassen können, testen wir sie. Um diese Tests zu skalieren und sie wiederholbar zu machen (sprich: nicht durch die Abwesenheit von Koffein beeinträchtigt), automatisieren wir sie.

In der Welt der Testautomatisierungs-Frameworks verspricht Cypress superschnelles und hilfreiches Feedback zu den Tests.
Da Cypress im 'UI-Modus' ausgeführt werden kann, können Sie live verfolgen, wie Ihr Test abläuft. CNN hätte es nicht besser machen können ;) Nach jedem Testbefehl kann der 'Vorher-Zustand' und der 'Nachher-Zustand' des DOM eingesehen werden, was sehr hilfreich ist, wenn Sie die zu testende Anwendung untersuchen möchten.

Aus meiner Erfahrung kann ich sagen, dass Cypress zwar einen schnellen Testrunner hat, es aber dennoch Gründe geben kann, warum Ihre Tests langsam laufen.
Dieser Artikel behandelt einige Gründe und wie Sie diese abmildern können, damit Sie das schnelle Feedback erhalten, das Sie verdienen.

Also eine Liste von Gründen, warum Ihre Cypress Testsuite langsamer sein könnte als nötig. Verwenden Sie diese Liste als Checkliste, um zu sehen, wo Sie sich verbessern können.

• [ ] Neueste Cypress-Version
• [ ] Analysieren (Ihr Projekt in Form halten)
• [ ] Automatisches Warten
• [ ] Parallelisierung
• [ ] Laden von Plugins
• [ ] Cypress Greb (Rauchtest)
  

  Cypress Version

  Stellen Sie sicher, dass Sie immer die neueste Cypress-Version verwenden. Ich habe Projekte gesehen, bei denen dies nicht der Fall war, und Projekte, die mehr als 1 Hauptversion 'hinterherhinkten', was schon einen echten Unterschied machen kann, wenn es um eine schnelle Feedbackschleife geht! In einigen dieser Fälle war ein Major - Upgrade dafür verantwortlich, dass die Tests schneller liefen, weil Fehler behoben wurden, die mit der Startzeit von Cypress zu tun hatten.

Ein Vorschlag ist die Verwendung eines "Bots", der alle Aktualisierungen Ihrer Abhängigkeiten für Sie automatisiert, z. B. Renovate oder Dependabot, der sich um die Aktualisierung Ihrer Cypress-Abhängigkeiten in Ihrer package.json sowie des Cypress-Docker-Images kümmert, das Sie in Ihrer Pipeline-Definitionsdatei verwenden sollten.

Analysieren (halten Sie Ihr Projekt in Form)

Die Analyse Ihrer Testergebnisse kann ein ganzer Blog für sich sein (Notiz an mich selbst: Schreiben Sie einen Blog über Testanalyse), aber lassen Sie uns hier eine kurze Version behandeln.

Meiner Erfahrung nach habe ich oft erlebt, dass die Leute, wenn der Testcode einmal geschrieben ist, nicht mehr darauf achten. Sie konzentrieren sich auf das, woran sie gerade arbeiten, nämlich auf die Funktion, an der sie arbeiten, und vergessen dabei, dass es eine ganze Welt von Code, Pipeline-Output oder Metriken gibt, aus denen nicht gelernt wird. Das kann Ihrer schnellen Feedbackschleife so 'schaden', dass sie vielleicht sogar noch schneller wird als sie ohnehin schon ist.

Der Schwerpunkt, den ich versuche, in ein Team einzubringen, besteht darin, Zeit einzuplanen (sagen wir 1 Stunde pro Woche), um die Projektergebnisse (Pipelines, Metriken, Testergebnisse) zu analysieren und zu erfahren, ob die Dinge immer noch wie erwartet funktionieren.

Um zu den Cypress-Tests zurückzukehren, müssen Sie sich die von den Kollegen geschriebenen Spezifikationen ansehen und prüfen, ob sie noch sinnvoll sind. Was sehe ich? Verstehe ich immer noch, was in den Tests vor sich geht? (Wenn nicht: Was kann ich daraus lernen?) Sind die richtigen 'Best Practices' vorhanden? Wie schnell läuft meine Testsuite? Könnte sie schneller laufen? Analysieren, analysieren, analysieren, um zu verstehen.

Vielleicht gibt es eine Spezifikationsdatei, die einen cy.wait-Befehl enthält, aber jetzt, wo Sie mehr über Ihre Anwendung oder über Cypress gelernt haben, können Sie den Test anders angehen, so dass Sie den cy.wait-Befehl nicht mehr verwenden müssen. Und jetzt müssen Sie nicht mehr jedes Mal, wenn der Test läuft (sei es in der Cypress GUI oder in CI), eine bestimmte Zeit warten.

Oh, und wussten Sie schon, dass Sie das Timeout von Tests, Befehlen und Ihrer gesamten Testsuite ändern können?

Die Standardwartezeit für einen Cypress-Befehl beträgt 4000 Millisekunden. Das folgende Beispiel zeigt, wie die Wartezeit für einen bestimmten Befehl auf 10000 Millisekunden überschrieben wird.

Manche ziehen es vor, das Standard-Timeout innerhalb eines bestimmten Tests zu verlängern. Dies kann wie folgt geschehen:

Es ist möglich, den Standard-Befehls-Timeout in der Cypress-Konfigurationsdatei festzulegen. Auf diese Weise wird die gesamte Testsuite beeinflusst. Ausgenommen sind natürlich die Timeout-Einstellungen, die Sie in einer bestimmten Spec-Datei festlegen

Ein weiterer Teil der Analyse der Tests besteht darin, in der Cypress Cloud zu prüfen, ob die Tests unzuverlässig geworden sind.
Wenn dieselben Tests häufig von der Wiederholungsfähigkeit von Cypress abhängen, könnte man dies als 'Geruch' bezeichnen. Der Test könnte aufgrund einer Regression im Code unzuverlässig geworden sein.
Die Cypress Cloud verfügt über einige nette Funktionen für die Analysen, wie 'langsamste Tests', 'Top-Fehler' und 'unzuverlässige Tests'.

Verspotten / Stubben

Mit dem Cypress Command cy.intercept können Sie einen Aufruf einer API nachahmen.
Durch das Nachahmen Ihrer API benötigen Sie keine laufende API, bei der es sich oft um einen Backend-Dienst mit einer Datenbank handelt, und Sie müssen keine Datenbank für Ihre Tests seeden. Das spart Ihnen viel Zeit bei der Ausführung Ihrer Tests und ermöglicht Ihnen eine schnelle Feedbackschleife.

Ein Beispiel für eine solche Attrappe:

Dieses Beispiel fängt einen Post an eine API ab und gibt ein Body-Objekt mit einem bestimmten Schlüssel/Wert zurück. Dieser Aufruf trifft nie auf die eigentliche API, so dass es nicht notwendig ist, diese API (Dienst und Datenbank) für Testzwecke einzurichten und Sie können Ihren Test mit der zurückgegebenen Antwort fortsetzen.

Wenn Sie Ihre API-Aufrufe stubben, sollten Sie sich darüber im Klaren sein, dass es Tests geben sollte, die die Verbindung mit der API abdecken. Wenn Sie die API stubben, wissen Ihre Tests nicht, welche Änderungen an der API auftreten können. Daher können Sie Tests einrichten, die diese Änderungen aufspüren.

Es gibt verschiedene Ansätze, die das Thema der Implementierung einer geeigneten Teststrategie behandeln. Hier sind einige Links dazu:

• Test-Trophäe - Kent C Dodds
• Gleb Bahmutov
• Filip Hric - Testkreis
  

  Automatisches Warten

  Cypress verfügt über eine eingebaute Funktion namens Automatisches Warten. Im Gegensatz zum Befehl cy.wait(), bei dem Sie eine feste Zeitspanne warten müssen, bevor Sie mit Ihrem Test fortfahren können, funktioniert das automatische Warten wie ein Abfragemechanismus. Der Befehl wird wiederholt, und wenn der Befehl aufgelöst wird, wird er fortgesetzt.

Häufig wird dieses automatische Warten mit dem cy.intercept-Mechanismus verwendet. Sie können einen Alias zu Ihrem Intercept hinzufügen und dann warten, bis dieser Alias aufgelöst wird, und dann Ihren Test fortsetzen.

*Anmerkung: In diesem Beispiel wurde der Netzwerkanruf nicht abgefangen.

Parallelisierung *

Wenn Sie die Cypress Cloud aktivieren, erhält Ihre Testsuite noch mehr Superkräfte. Mit der Cypress Cloud können Sie Ihre Tests in der KI im Parallelmodus ausführen und so die Gesamtlaufzeit Ihrer Testsuite reduzieren. Ganz zu schweigen von den Erkenntnissen, die Sie aus all den anderen Funktionen der Cypress Cloud gewinnen können.

Schauen Sie sich einen Vortrag an, den ich bei der niederländischen Cypress-Community gehalten habe(Meetup-Aufzeichnung) , um mehr darüber zu erfahren, wie man die Cypress-Parallelisierung einrichtet.

Wenn Sie die Spezifikationsdateien Ihrer Testsuite parallel ausführen und die Cypress Cloud verwenden, informiert Sie das Cloud Dashboard darüber, wie viele CI-Runner Sie konfigurieren müssen, um Ihre parallelisierten Testläufe noch schneller zu machen:

Die Cypress Cloud verfügt über einige raffinierte Funktionen, die Ihnen zusammen mit der Parallelisierung ein noch schnelleres Feedback ermöglichen. Die Funktion heißt 'Run failed Tests First' (RFTF).

RFTF

• Noch ein Hinweis zur Parallelisierungsfunktion der Cypress Cloud. Wenn Sie sie auf dem kostenlosen Tier nutzen möchten, muss Ihr Projekt auf einem öffentlichen Repository Ihres CI-Anbieters bereitgestellt werden.
  Es gab einige Online-Diskussionen über die Preise der verschiedenen Cypress Cloud Tiers. Einen interessanten Twitter-Thread finden Sie hier:[Thread]

  Laden von Plugins

  Jedes Mal, wenn Cypress eine Spezifikationsdatei ausführt, werden erstens alle in Ihrer Plugin-Datei beschriebenen Plugins und zweitens die Spezifikationsdatei selbst geladen.

Wenn Sie Plugins installiert haben, die für bestimmte spezifische Dateien verwendet werden sollen, müssen Sie diese nicht in Ihre 'globale' Plugin-Datei aufnehmen, damit sie nur bei Bedarf geladen werden. Das kann Ihnen eine Menge Zeit sparen! Apropos "halten Sie Ihre Testsuite in Form"!

Zypresse Grep

Cypress Grep ist ein Plugin, das den Cypress Testrunner um einige zusätzliche Funktionen erweitert. Die Auswahl von Spezifikationsdateien mit Hilfe von Globs oder sogar die Auswahl bestimmter Ordner für einen Smoke-Test entfällt. Mit diesem Plugin können Sie Ihre Tests kennzeichnen und diese Kennzeichnung verwenden, um festzulegen, welche Tests in einem bestimmten CI/CD-Job (oder sogar lokal) ausgeführt werden sollen.
Angenommen, Sie möchten einige Ihrer Tests als smoke (für Smoke-Tests) kennzeichnen, dann können Sie ganze Spezifikationsdateien kennzeichnen, indem Sie ein 'describe' wie folgt kennzeichnen:

oder bestimmte Tests durch die Kennzeichnung eines 'es'

Wenn Sie nun Ihren Test in CI mit

Es werden nur die Tests ausgeführt, die mit dem Tag 'smoke' versehen wurden.

Fazit

Es gibt eine Reihe von Punkten, auf die Sie achten sollten, um Ihre Testsuite in Form zu halten und Ihre schnelle Feedbackschleife in Frage zu stellen.

Verwenden Sie Mocking und Stubbing zusammen mit Cypress Aliases, damit Ihre Tests wirklich schnell laufen. Verwenden Sie Cypress Grep, um nur die von Ihnen ausgewählten Tests im CI auszuführen. Nutzen Sie die Parallelisierung der Cypress Cloud, um Ihre CI-Laufzeit zu senken, indem Sie die neueste Cypress-Version für den Testrunner verwenden.
Verwenden Sie die Plugins nur dort, wo es wirklich notwendig ist, um Ihre Testsuite schlank zu machen. Und zu guter Letzt: Analysieren Sie, analysieren Sie, analysieren Sie, um zu verstehen.

Wenn Sie an einer gründlichen Schulung zur Verwendung von Cypress in Ihren Projekten interessiert sind, wenn Sie ein Entwickler oder Tester werden wollen, der in der Lage ist, großartige Tests zu schreiben und eine E2E-Testsuite mit Cypress einzurichten, sollten Sie sich diese Schulung ansehen: <Link>

Wenn Sie an einem anderen Artikel interessiert sind, den ich über die Verwendung der Parent-Child-Pipelines von Gitlab zum Auslösen von Cypress E2E-Tests geschrieben habe, finden Sie meinen Beitrag hier: Link

Ich bin neugierig, wie sich die Anwendung dieser Aufmerksamkeitspunkte bei Ihnen auswirkt!
Sie können mir gerne über LinkedIn[Link] oder Twitter @joelgrimberg eine Nachricht zukommen lassen.