Einführung in automatisierte End-to-End-Tests

Video-Transkript

Wir haben ChatGPT verwendet, um die Grammatik und Syntax des Transkripts zu verbessern.

Guten Morgen, allerseits. Ich freue mich, dass Sie alle hier sind, und ich hoffe, Sie sind koffeinhaltig. Falls wir noch nicht die Gelegenheit hatten, uns kennenzulernen: Mein Name ist Paul. Ich habe einige Jahrzehnte an der Universität von Missouri gearbeitet, wo ich für die Entwicklung und Pflege der Prozesse und Arbeitsabläufe zur Verwaltung der WordPress-Sites zuständig war. Ich habe also eine lange Erfahrung sowohl im Hochschulwesen als auch mit WordPress. Jetzt bin ich Developer Relations Engineer bei Platform.sh. Falls Sie uns noch nicht kennen: Wir sind ein sicherer, unternehmenstauglicher Platform-as-a-Service-Anbieter. Wir nehmen Ihnen die Komplexität des Cloud-Infrastrukturmanagements ab, damit Sie und Ihre Teams mehr Zeit haben, auf die sich ändernden Anforderungen Ihrer Institution zu reagieren und Ihre institutionellen Aufgaben zu unterstützen, und weniger Zeit, sich mit der Cloud-Infrastruktur zu befassen. Ob vor Ort oder aus der Ferne, ob WordPress, Drupal, Django, Gatsby oder was auch immer Sie benötigen, Sie können all dies von einem zentralen Standort aus verwalten. Wir können eine entscheidende Rolle bei Ihren End-to-End-Tests spielen.

Bevor ich nun anfange, möchte ich Sie vor einigen Dingen warnen. Die erste ist, dass ich kein Testexperte bin. Diese Präsentation ist, wie die meisten meiner Präsentationen, entstanden, weil mir eine Aufgabe gestellt wurde. Mir wurde gesagt, ich solle End-to-End-Tests zu einigen der Dinge hinzufügen, die wir unterstützen. Ich wusste nicht viel darüber, also musste ich es lernen. Dabei dachte ich, dass vielleicht auch andere davon lernen könnten. Ich fragte den WordPress-Kanal, ob jemand daran interessiert sei, und erhielt eine große Resonanz. So kam diese Präsentation zustande.

Die zweite Sache ist, dass ich das alles heute live machen werde, und Sie wissen ja, wie Live-Demos ablaufen, also wünschen Sie mir Glück. Ich werde wahrscheinlich die vollen 45 Minuten in Anspruch nehmen.

Meine Ziele für Sie, wenn Sie heute hier weggehen, sind:

Ich möchte, dass Sie in der Lage sind zu definieren, was End-to-End-Tests sind.
Ich möchte, dass Sie sich an mindestens einen Vorteil erinnern können, den End-to-End-Tests für Ihre Arbeitsabläufe und Ihr Unternehmen mit sich bringen.
Ich möchte, dass Sie verstehen, was Cypress ist, wie man es installiert, wie man es konfiguriert und wie man zumindest den ersten Test schreibt.
Ich möchte, dass Sie mit den Strategien und Best Practices vertraut sind und über das gesamte Grundlagenwissen verfügen, das Sie benötigen, um den zweiten, dritten und vierten Test zu erstellen.
Wie viele von Ihnen führen also bereits irgendeine Form von automatisierten Tests in Ihren Arbeitsabläufen durch? Wunderbar. Wie viele von Ihnen führen End-to-End-Tests durch? Ein paar? Okay, für alle anderen: Wenn Sie eine Aufgabe bekämen oder ein neues Feature oder eine neue Funktionalität schreiben müssten, wie würden Sie überprüfen, ob das, was Sie geschrieben haben, so funktioniert, wie Sie es erwarten?

(Antwort aus dem Publikum) "Besuchen Sie die Website."

Genau, Sie besuchen die Website und machen es manuell, richtig? Nun, das ist alles, was automatisierte Tests ausmacht. Beim End-to-End-Testing wird der echte Benutzer nachgeahmt und versucht, die Schritte zu wiederholen, die er ausführen würde, um dann zu überprüfen, ob die Anwendung genau das getan hat, was wir erwartet haben. Das ist alles, was End-to-End-Tests ausmacht - es ist lediglich die Automatisierung dieses manuellen Prozesses.

Das bringt einige große Vorteile mit sich. In vielen Fällen können wir Probleme mit unserer Software erst dann aufdecken, wenn sie in einem realen Szenario funktioniert, in dem sie tatsächlich mit der Datenbank interagiert, die Benutzeroberfläche vor sich hat und mit all den Diensten von Drittanbietern verbunden ist. Wir können diese Probleme erst dann aufdecken, wenn wir die Software so getestet haben, wie es der Benutzer tun würde. Aber das braucht Zeit, und hier kommen die Vorteile der Automatisierung ins Spiel. Außerdem können wir diese Fehler aufspüren, bevor sie auftreten - bevor wir sie für die Produktion freigeben -, und es ist viel weniger kostspielig, sie zu beheben. Sobald unsere Tests erfolgreich sind, haben wir ein sehr hohes Maß an Vertrauen, dass das, was wir in die Produktion einführen oder bereitstellen, genau so funktioniert, wie wir es erwartet haben, und dass es sich nicht negativ auf die Benutzererfahrung auswirkt, was letztendlich unsere Qualitätssicherung erhöht. Wenn Sie schließlich mit Abteilungen zusammenarbeiten, die Ihnen eine Reihe von gewünschten Funktionen vorgeben, und Sie Ihre Tests so schreiben können, dass sie diese Funktionen verifizieren, dann können Sie sicherstellen, dass Sie mit den geschäftlichen Anforderungen übereinstimmen.

Wie unterscheiden sich nun End-to-End-Tests von anderen Arten von Tests? Nun, wenn Sie mit der Pyramide der automatisierten Teststrategien vertraut sind, stehen die Unit-Tests ganz unten. Wir führen eine ganze Reihe davon durch, aber sie sind isoliert und testen nur einzelne Teile. Dann kommen wir zu den integrierten Tests, bei denen wir unseren Code mit externen Diensten testen. Wir führen weniger davon durch, weil sie etwas schwieriger zu bewerkstelligen sind. An der Spitze stehen die End-to-End-Tests, bei denen wir alles testen. Da wir aber alles testen, ist es viel komplexer, also führen wir weniger davon durch, mit dem Ziel, dass diese manuellen Tests nur sehr selten vorkommen.

Falls Sie mit den beiden anderen Methoden nicht vertraut sind: Unit-Tests basieren auf der Idee, dass man in einer idealen Welt - und ich weiß, dass die Hochschulbildung nicht ideal ist - einen Test schreibt, um den kleinsten Teil der Funktionalität zu testen, der möglich ist. Dann schreiben Sie den Test, bevor Sie die Funktionalität schreiben. In Ihrer Programmiersprache ist das normalerweise eine Funktion oder eine Methode. Während Sie diese Funktion oder Methode schreiben, testen Sie sie immer und immer wieder, aber Sie isolieren sie von allen externen Anforderungen, damit Sie nur diese Funktionalität testen. Das ist der Grund, warum wir das sehr oft tun, weil wir so ein unmittelbares Feedback bekommen. Sobald wir grünes Licht bekommen - wir bestehen alle Unit-Tests -, gehen wir zu den integrierten Tests über. Wir können also einzelne Einheiten, die wir getestet haben, in Gruppen zusammenfassen und sie als Gruppe testen. Wir könnten unseren Code nehmen und mit externen Abhängigkeiten oder externen Diensten testen, um Probleme in der Kommunikation zwischen unserem Code und diesen externen Abhängigkeiten aufzudecken. Dann kommen wir wieder zu den End-to-End-Tests, bei denen wir alles von Anfang bis Ende nachahmen und versuchen, genau wie ein Benutzer zu überprüfen, ob unsere Funktionen funktionieren.

Der Grund dafür, dass wir das viel seltener tun müssen, ist, dass es teurer ist. Das kann sowohl monetär sein, weil wir eine Umgebung oder einen Server einrichten müssen, um diese Tests durchzuführen, als auch personell - es kostet Zeit, all diese Tests zu schreiben. Gelegentlich erwähne ich auch Sprödigkeit. Es kann auch ein bisschen schwierig sein, sie zu warten. Nehmen wir an, Sie schreiben eine Funktion, mit der Sie ein Menüelement in die Verwaltungsleiste einfügen wollen. Dann soll der Benutzer irgendwo hingehen, er soll ein Panel haben, einige Informationen ausfüllen und etwas tun. Wir können den Test schreiben, überprüfen, ob alles korrekt funktioniert, und dann beschließt jemand in der nächsten Iteration, die ID dieses Menüelements zu ändern. Plötzlich können wir diesen Menüpunkt in unserem Test nicht mehr wie zuvor aufrufen, und der Test wird abgebrochen, obwohl die Funktionalität weiterhin gegeben ist. Das ist also nur ein Beispiel für einen spröden Test. Wir müssen uns darüber im Klaren sein, dass diese ein wenig spröde sein können.

Also, Cypress. Wie viele von Ihnen haben schon von Cypress gehört? Hat schon mal jemand damit gespielt? Ein paar? Okay, für alle anderen: Cypress ist ein Open-Source-Framework für automatisierte Tests, dessen Hauptziel bei seiner Entwicklung darin bestand, die Zeit zwischen der Installation und dem Schreiben von Tests zu verkürzen. In früheren Zeiten - ich schätze, es war das dunkle Zeitalter - war eine Menge Konfiguration und Einrichtung erforderlich, um die Automatisierung des Browsers aufzubauen. Ihr Ziel war es, dass Sie so schnell wie möglich mit dem Schreiben von Tests beginnen konnten.

Jetzt bringt es einige spezifische Vorteile mit sich. Es ist Open Source; sie haben ein optionales SaaS-Produkt. Es verwendet weder Selenium noch WebDrivers, sondern eine Electron-Anwendung und bettet Ihre Anwendung - Ihre Webanwendung - in Electron ein, was bedeutet, dass alles innerhalb des Browsers abläuft, was sehr, sehr schnell ist. Derzeit werden alle Browser unterstützt, außer Safari, das auf der Roadmap steht. Ein weiteres cooles Feature ist die Zeitreise und Testwiederholung. Wenn Sie also einen Test durchführen, können Sie zurückgehen und den Test wiederholen, um zu sehen, wie sich der Zustand Ihrer Anwendung beim Durchlaufen aller Schritte ändert. Die Zeitreise ermöglicht es Ihnen, zu einem einzelnen Schritt zurückzugehen und den Zustand Ihrer Anwendung zu sehen, wie sie sich verhält, und genau zu beobachten, was bei jedem Schritt passiert, während Sie sich vorwärts und rückwärts bewegen. Darüber hinaus ist alles, was Sie auf der Konsole ausgeben, in diesem Schritt verfügbar, und es stehen Ihnen eine ganze Reihe von Debugging-Tools zur Verfügung, mit denen Sie Ihren Test debuggen und genau herausfinden können, warum er fehlschlägt.

Ein weiteres cooles Feature ist das automatische Warten. Wenn Sie also eine Website besuchen, folgt das Programm automatisch den Weiterleitungen, bis es eine 200 erreicht. Sobald die Seite erreicht ist, wird gewartet, bis das Ladeereignis der Seite ausgelöst wird, bevor es weitergeht. Wenn Sie nach einem DOM-Element fragen, z. B. in einer dynamischen Anwendung, wird automatisch gewartet, bis dieses DOM-Element verfügbar ist oder eine Zeitüberschreitung eintritt. Das automatische Warten ist also eine großartige Funktion, mit der Sie sicherstellen können, dass die Dinge so geladen werden, wie Sie es wünschen.

Auch die Kontrolle des Netzwerkverkehrs ist wirklich cool. Sie können jede Anfrage abfangen - also jede Anfrage an einen Endpunkt oder einen Ort - Sie können sie abfangen, untersuchen, die Daten ändern, die gesendet werden, und wenn die Nutzdaten zurückgegeben werden, können Sie die Nutzdaten abfangen und manipulieren, oder Sie können sie abfangen und Ihre eigenen Daten zurückgeben, ohne dass sie zurückgegeben werden. Eine Menge unglaublich cooler Funktionen.

Cypress ist aber nicht die einzige Lösung in der Stadt. Es gibt mehrere Alternativen zu Cypress, darunter Playwright, Nightwatch, WebDriver, Codeception, usw. Ich kann Ihnen sagen, dass das Go-Team - ich glaube, es war im Jahr 2019 - an Cypress gearbeitet hat, ohne mich zu zitieren. Irgendwann zwischen 2021 und 2022 sind sie dann zu Puppeteer gewechselt, das von Google unterstützt wird, und seit Februar dieses Jahres arbeiten sie nun mit Playwright, das von Microsoft unterstützt wird. Ich persönlich habe nach mehr als 20 Jahren im Hochschulbereich großen Respekt vor diesen Tools, auf die ich mich lange Zeit verlassen kann, oder? Ich hatte nie die Möglichkeit, meine Werkzeuge innerhalb von 18 Monaten zu wechseln; das war keine Option. Ich brauchte etwas, auf das ich mich 3 bis 5 Jahre lang verlassen konnte, und deshalb bleibe ich bei Cypress, weil ihre Dokumentation hervorragend ist. Es gibt nicht nur ausführliche Dokumente, sondern auch Leitfäden, Tutorien, Videos und jede Menge Beispielcode, auch hier mit dem Ziel, dass man so schnell wie möglich einen Test schreiben kann.

Abgesehen davon werde ich vielleicht nächstes Jahr wieder über Playwright sprechen, ich bin mir nicht sicher, aber im Moment ist es Cypress.

Gut, also installieren Sie Cypress, wieder so schnell wie möglich, richtig? Es ist so einfach wie eine npm-Installation. Und das ist, wo wir auf den Live-Code wechseln, so starten Sie mir Glück wünschen, dass wir einige Internet hier haben. Also, ich fange an und starte das. [Pause für Aktion]

Das klickt nicht. Das war's. Was ist denn da los? Oh, es ist hier hinten. Das ist ja interessant. Versuchen wir, npm install zu löschen, und das war's. Das ist alles, was man tun muss, um es zu installieren. Es lädt automatisch die Abhängigkeiten herunter und baut die Electron-App auf der Grundlage deines Betriebssystems. Es sollte eigentlich... da ist es, es ist fertig.

Um Cypress zu konfigurieren, müssen wir es nur noch öffnen. Also, ich öffne das hier. Es geht los und baut die App. Das erste Mal, wenn sie läuft, sagt sie: "Hey, du hast keine Konfigurationsdateien. Was machen wir heute? Führen wir End-to-End-Tests oder Komponententests durch?" Wir konzentrieren uns auf Ende-zu-Ende. Sobald Sie darauf klicken, heißt es: "Okay, ich konfiguriere alles für Sie im Hintergrund." Nach der Aktualisierung habe ich eine Konfigurationsdatei und eine Sammlung von unterstützenden Dateien, und das war's. Das ist alles, was Sie tun müssen, um es zu konfigurieren. Danach müssen Sie nur noch den Browser auswählen, in dem Sie die Tests durchführen möchten. Ich führe meine Präsentation heute in Chrome aus, also werde ich Firefox verwenden. Starten Sie ihn einfach. Und dann, genau wie bei den Konfigurationen, heißt es sofort nach dem Start: "Ich sehe keine Testdateien. Testdateien werden in Cypress als Spec-Dateien bezeichnet. Sie sagt: "Soll ich Ihnen ein paar Gerüstdateien geben, ein paar Beispiele, damit Sie anfangen können, Ihre eigenen zu bauen, oder möchten Sie gleich Ihren ersten Test schreiben?" Lassen Sie uns unseren ersten Test schreiben. Ich nenne diesen Test "first" und erstelle ihn dann.

Im Hintergrund wurde diese Datei in ein Verzeichnis namens e2e geschrieben. Kann jeder diesen Code sehen? Ist das groß genug? Das ist groß genug? Nun gut. Was ich tun möchte, ist, während wir das durchgehen, all diese Teile aufzuschlüsseln.

Der erste Teil, den wir haben, heißt "describe". Der describe-Block ist einfach ein Organisationswerkzeug für Sie. Sie können mehrere describe in einer einzigen spec-Datei haben. Sie können describe innerhalb einer describe-Datei verschachteln. Er ist einfach ein Organisationsmittel. Er benötigt zwei Parameter: einen Titel, der im Testwerkzeug angezeigt werden soll, um Ihre Testgruppe zu identifizieren, und eine Callback-Funktion. Wir fügen unsere Tests in die Rückruffunktion ein.

Das nächste Element ist "it". Dieser Block enthält zwei Dinge: Er enthält unseren Test und benötigt wiederum eine Bezeichnung, die im Testtool angezeigt wird, damit wir den laufenden Test identifizieren können, sowie eine weitere Rückruffunktion. In diese Callback-Funktion fügen wir unsere Aktionen und Behauptungen ein, mit denen wir einige Dinge in Angriff nehmen wollen.

Wenn wir also eine Webanwendung testen, was ist das erste, was Sie wahrscheinlich tun müssen? Sie müssen in die Anwendung gelangen, richtig? Normalerweise ist eines der ersten Dinge, die man tut oder benutzt, cy.visit. Damit wird eine URL geladen. Es wird standardmäßig eine GET-Anfrage sein. Es wird allen 300 Weiterleitungen folgen, bis es eine 200 erreicht, und sobald es diese 200 erreicht hat, wird es warten, bis die Seite geladen ist und feuert. Ich gehe also zurück in unseren Code. Ich werde dies aktualisieren. Es ist ein bisschen schwer zu sehen mit all dem anderen Zoom-Zeug, also wenn ich etwas falsch schreibe, nehmen wir es einfach hin. [Pause für Aktion]

Hier steht: "Seite hat gültigen Titel". Ich glaube nicht, dass ich das völlig übersehen habe. Wir machen weiter und führen das aus. Starten wir es. [Pause für Aktion]

Oh, ich vergaß zu erwähnen, dass ich DDEV verwende. Kennt sich jemand mit DDEV aus? Ein paar von Ihnen? DDEV ist eine lokale Entwicklungsumgebung. Ich benutze es oft, weil wir eine Integration damit haben, die es mir ermöglicht, meine Produktionsseite zu klonen, was ich ebenfalls vergessen habe zu erwähnen. Ich habe eine Produktionssite. Das ist meine Produktionssite. Damit kann ich also von Platform.sh aus meine Produktionssite lokal in DDEV klonen. Ich werde das nehmen, also sage ich DDEV. Das ist das Richtige, da haben wir es. Das ist also die URL, die meiner lokalen Instanz zugewiesen ist. Ich gehe zurück in meinen Test. Aktualisieren wir das. Speichern Sie das und führen Sie den Test aus. [Pause für Aktion]

Los geht's. Jetzt können wir sehen, dass wir... hoffentlich können Sie das sehen. Das ist die Homepage. Das war der Titel, den ich der Beschreibung gegeben habe, und dann benennen Sie den Test selbst. Der Testkörper besteht derzeit nur aus dem Besuch der Website.

Gut, wenn wir die Seite besucht haben, was müssen wir dann tun? Mit anderen Worten, ich möchte überprüfen, ob diese Seite das ist, was ich erwarte.

[Publikumsreaktion] "Überprüfen Sie den Seitentitel."

Ja, überprüfen Sie den Seitentitel, richtig? Sie müssen ein DOM-Element holen und dann überprüfen, ob es Daten enthält, eine Klasse hat oder sichtbar ist. Wir müssen auf irgendeine Art und Weise überprüfen, ob die Seite das ist, was wir dachten, dass sie sein würde. Mit cy.get können Sie also ein oder mehrere DOM-Elemente von der Seite abrufen. Es wird dieses DOM-Element an das nächste Element zurückgeben, das wir mit ihm verketten. Es wird immer - und das ist wichtig zu wissen - von cy.root ausgehen, was normalerweise die Wurzel des Dokuments ist. Wenn ich also cy.get("main") und dann eine weitere Verkettung mit cy.get durchführe, wird die Suche nicht darauf beschränkt, sondern geht zurück zur Wurzel. Nun, es gibt andere Möglichkeiten, das zu tun, aber nicht mit cy.get.

Mit cy.get werden wir also unsere Elemente abrufen, und genau wie die anderen wird es automatisch immer wieder versuchen, dieses DOM-Element abzurufen, bis es entweder existiert oder wir eine Zeitüberschreitung erreichen. Ich gehe also zurück in unseren Code und füge cy.get ein. Holen wir uns den Titel - hier ist er. Und was müssen wir dann tun? Ihm sagen, was er sein soll, richtig? Die Methode, die wir verwenden, ist also should. Wir verwenden die should-Methode für dieses DOM-Element, und das ist es, was unsere Assertion oder unsere Validierung erstellen wird. Sie akzeptiert eine Chai-kompatible Zeichenkette. Chai ist eine Behavior Driven Development (BDD) Test- und Test-Driven Development (TDD) Assertion-Bibliothek. Sie erlaubt es Ihnen, einfache englische Wörter zu verwenden, um die Behauptung oder Validierung zu beschreiben, die Sie machen wollen. Wenn ich also das Element title eingebe und eine Behauptung aufstelle, wird diese, wenn sie erfolgreich ist, an das nächste Element weitergegeben, was bedeutet, dass ich Behauptungen verketten kann. Es wird automatisch immer wieder versuchen, eine positive Behauptung zu erhalten, bis es entweder eine Zeitüberschreitung erreicht oder endgültig scheitert.

In diesem Fall werde ich das erste Mal eine Pause einlegen, damit wir es sehen können. Ich werde sagen, dass "WP Campus 2023" enthalten soll. Führen wir den Test aus und stellen fest, dass er fehlschlägt, weil dies nicht 2023 ist, richtig? Ich habe also ein nettes kleines rotes Häkchen - Sie können das rote Häkchen vielleicht nicht sehen - oben neben dem Test, was bedeutet, dass der Test fehlgeschlagen ist. Die Behauptung hat nicht bestanden. Ich komme jetzt wieder rein und kann das hoffentlich beheben. So, das war's. Jetzt ist es tatsächlich... es beobachtet auch, also wird es Ihren Test beobachten und ihn automatisch wiederholen. Wahrscheinlich hat es den Test bereits wiederholt, und das hat es auch. Jetzt habe ich also eine schöne grüne Bestätigung. Ich bin auch farbenblind, also wenn das nicht grün ist, sagt mir das bitte jemand. Ich nehme an, dass es grün ist. Okay, wir haben also eine grüne Behauptung und ein grünes Häkchen, was bedeutet, dass Sie jetzt gerade Ihren ersten Test abgeschlossen haben. So, das war's.

Ich weiß, dass das ein sehr einfacher Test ist, aber für mich ist der schwierigste Teil beim Erlernen einer neuen Sache, die Sache zu installieren, zu konfigurieren und dann etwas zu tun. Wenn Sie jetzt zurückgehen und es installieren, konfigurieren - was im Grunde nur bedeutet, dass Sie es öffnen - und dann einen einfachen Test schreiben, der lautet: "Gehen Sie auf meine Homepage und stellen Sie sicher, dass der Titel richtig ist", dann haben Sie es jetzt in Ihren Arbeitsablauf integriert. Das nächste Mal wird es viel einfacher sein.

Wenn Sie mit dem Schreiben der nächsten Tests beginnen, sollten Sie einige Dinge im Hinterkopf behalten. Erstens: Das Schwierigste beim Schreiben von Tests ist, zu wissen, was man testen will. Das ist der schwierigste Teil. Mein Vorschlag wäre also, dass Sie das nächste Mal, wenn Sie eine Aufgabe erhalten, eine Funktion, die in Ihre Website integriert werden soll, alle Schritte aufschreiben, die Sie unternehmen, um sie manuell zu überprüfen. Gehen Sie hinein und sagen Sie: "Okay, ich habe hier geklickt, ich habe hier geklickt, ich habe hier geklickt, ich habe hier geklickt", und am Ende: "So sollte es auf dieser Seite aussehen. So sollte sie reagieren." Zerlegen Sie das Ganze in immer kleinere Schritte und wandeln Sie diese Schritte und Aktionen dann in einen Test um. Führen Sie diesen Test dann so lange durch, bis Sie herausgefunden haben, wie Sie sicherstellen können, dass Sie die Funktion richtig schreiben, solange sie funktioniert. Stellen Sie sicher, dass Sie sowohl die erfolgreichen als auch die weniger erfolgreichen Pfade testen.

Damit meine ich, wenn wir zum Beispiel ein Anmeldeformular testen, wäre ein glücklicher Pfad der folgende: Ich gebe einen korrekten Benutzernamen und ein korrektes Kennwort ein, klicke auf Absenden, gelange in den Verwaltungsbereich und oben rechts steht mein Benutzername. Das ist der glückliche Weg. Ein unglücklicher Pfad wäre: Ich gebe einen Benutzernamen und ein Kennwort ein, die nicht korrekt sind, klicke auf "Absenden", gehe zurück zum Formular und erhalte eine Fehlermeldung. Wir wollen also sicherstellen, dass wir den unglücklichen Pfad testen, um zu gewährleisten, dass die Anwendung immer noch so funktioniert, wie wir es erwarten, auch wenn der Benutzer nicht die richtigen Schritte durchführt.

Ein guter Test sollte drei Phasen abdecken. Die erste ist die Einrichtung des Anwendungsstatus - wir werden später mehr über den Anwendungsstatus sprechen. In der nächsten Phase werden diese Aktionen ausgeführt, wobei wiederum der Benutzer imitiert wird, der die zum Testen dieser Funktion erforderlichen Schritte durchführt. Der letzte Schritt besteht darin, eine Aussage über den resultierenden Zustand zu treffen. Sie können dies als "arrangieren, handeln und behaupten" oder als "gegeben, wenn, dann" bezeichnen. Denken wir also an den ersten Test zurück: Wenn ich ein anonymer Benutzer bin und die Homepage besuche, sollte der Titel der Seite "WP Campus 2024" lauten. Macht das Sinn? Denken Sie also in diesem Sinne: Wenn ich einen bestimmten Zustand der Anwendung erreiche und diese Schritte ausführe, sollte die Anwendung auf diese Weise aussehen.

Ein weiterer Punkt, an den Sie denken sollten, wenn Sie diese Tests schreiben, ist, dass Sie versuchen sollten, sie so zu gestalten, dass sie voneinander unabhängig sind. Das heißt, wenn ich vier Tests habe, möchte ich nicht, dass Test drei von dem Zustand abhängt, den Test eins erzeugt hat. Denn erstens: Test eins könnte fehlerhaft ablaufen und mir einen falschen Zustand hinterlassen; oder zweitens: er könnte fehlschlagen und mir einen Zustand hinterlassen, der sich negativ auf Test drei auswirkt. Wir wollen also sicherstellen, dass jeder Test unabhängig von den anderen laufen kann.

Sind Sie bereit, den zweiten Test zu schreiben? Das ist mein Ziel. Okay, ich werde jetzt hier eine zweite Datei erstellen. Gehen Sie da rauf. Wir legen eine neue JavaScript-Datei an, die ich auth.cy.js nenne. Sagen wir, ich beschreibe, und wir werden dies als auth test beschreiben. Dann haben wir unseren Rückruf. Und dann werde ich es mit auth machen. So weit, nichts allzu Kompliziertes. Rückruf-Funktion, viele Rückrufe. Und was ist das erste, was ich tun muss, wenn ich das Anmeldeformular testen will? Ich muss das Anmeldeformular besuchen, richtig? Ich gehe also zu cy.visit. Ich gehe zurück zu DDEV, nehme wieder meine Adresse, komme zurück und sage: "Besuche es mit wp-login.php". Kann jemand ein Problem erkennen, das ich soeben zwischen auth.cy.js und first.cy.js geschaffen habe, insbesondere beim Besuch?

Wo befindet sich diese URL gerade? "Homepage". Homepage von wo aus wird sie ausgeführt? "Lokal". Was ist, wenn ich meine End-to-End-Tests in einer gemeinsamen Entwicklungsumgebung ausführen muss? Was ist, wenn ich sie in einer Staging-Umgebung, einer PR-Umgebung oder irgendwo anders ausführen muss? Nun gut, wir müssen kurz über die Konfiguration sprechen. Eine der Optionen in der Konfigurationsdatei ist etwas, das baseUrl genannt wird. baseUrl erlaubt es uns, eine Domäne zu definieren, und dann wird allen Aufrufen von cy.visit oder cy.request, die relativ sind, dies vorangestellt. Der Clou ist jedoch, dass sie durch andere Umgebungsvariablen überschrieben werden kann. Cypress hat also eine Verarbeitungsreihenfolge für Umgebungsvariablen. Für die spezielle baseUrl-Variable oder andere Umgebungsvariablen, die wir erstellen müssen, können wir sie entweder in die Konfiguration aufnehmen, aber wir können auch eine .env-Datei schreiben, die diese überschreibt. Wenn das System, auf dem wir cypress run oder cypress open ausführen, Umgebungsvariablen hat, denen CYPRESS_ vorangestellt ist, werden diese automatisch geparst und überschrieben. Oder wir können bei der Ausführung von Cypress auch Überschreibungen für die Konfiguration oder die Umgebungsvariablen übergeben. Oder - es steht nicht einmal auf der Folie - in einem einzelnen Test können Sie eine Konfiguration oder diese Umgebungsvariablen überschreiben, was uns eine Menge Flexibilität bietet. Das bedeutet, dass wir unsere Tests so schreiben können, dass wir sie überall ausführen können und uns nicht darum kümmern müssen, den Test für eine bestimmte Umgebung zu ändern.

Ich öffne also die Konfigurationsdatei und füge die baseUrl hinzu. Ich werde sagen, dass normalerweise alle anderen im Team https://local.site/ verwenden und ich der Außenseiter bin. Gut, wenn ich das jetzt ausführe - sehen Sie, Cypress hat sich geschlossen - und zurückkomme, sagt es: "Hey, ich kann da nicht hin, weil da nichts ist", richtig? Wenn ich also wieder reinkomme, Cypress zuerst schließe, Cypress schließe, dann führe ich das noch einmal aus. Ich komme zurück in meine Testumgebung. Können Sie unten etwas sehen? Hoffentlich. Ich werde einen Export durchführen, bei dem ich baseUrl gleich der Adresse setze, die ich zuvor verwendet habe. Okay, ich fahre fort und mache das. Ich werde wieder npx open ausführen. [Pause für Aktion]

Ups, zu weit hergeholt. So, das war's. Und dann aktualisiere ich diese beiden Tests in meinen Tests hier. [Pause für Aktion]

Aktualisieren Sie diese Tests. [Pause für Aktion]

Diesen hier und meinen Autorisierungstest. Das war's. Wenn wir diese Tests speichern und zurück nach Cypress gehen, starten wir die Testumgebung neu. [Pause für Aktion]

Los geht's. Und wenn ich jetzt first.cy.js ausführe, gehen wir immer noch zu unserer lokalen Instanz zurück. Und wenn ich auth.cy.js ausführe, landen wir bei der Anmeldung. Jetzt muss ich einen PR-Antrag stellen, und ich habe einen Workflow, der eine Kopie dieser Umgebung erstellt. Ich muss meinen Test nicht ändern; es wird alles funktionieren. Ich kann sie direkt in dieser Umgebung ausführen, ohne meinen Test ändern zu müssen.

Wenn wir nun das Anmeldeformular testen, was müssen wir als nächstes tun? Den Benutzernamen eingeben? Wir müssen einen Benutzernamen und ein Passwort eingeben. Das Tolle an dieser Umgebung ist, dass diese kleine Schaltfläche neben der URL Ihnen einen Elementvorschlag für die Auswahl anzeigt - eine Menge Wörter. Ich klicke also darauf, und während ich hier herumfahre, wird gesagt: "Hey, hier sind all diese verschiedenen Elemente, die Sie auswählen können." Wenn ich darauf klicke, habe ich die Möglichkeit, sie in die Zwischenablage zu kopieren. Jetzt kann ich zurück in meinen Test gehen und sagen: "Gut, wir gehen hier rein und holen uns dieses Element." Eine Sache, die ich gelernt habe, schlage ich vor: Machen Sie ein clear() auf dem Element. Das löscht das Element, falls es einen Platzhaltertext oder etwas anderes enthält. Und von dort aus kann ich "bob" eingeben. Und was ist das nächste Element, das wir brauchen? Das Passwort. Manchmal wird der Vorgang nicht wiederholt; die Auswahl wird nicht immer wiederholt. Lassen Sie uns das noch einmal nehmen. Gehen Sie hier rein, und wir lassen Sie eingefügt. Und los geht's. Und noch ein clear(), und noch einmal "123" eingeben. Speichern Sie das. Gehen Sie zu unserem Test über. Jetzt haben wir "bob" und "123". Was ist das letzte, was wir tun müssen?

["Enter".

Ich habe zwei Dinge gehört. Ich habe "Enter" und "Click" gehört. Sie können beides tun. Sie können also das Drücken einer Taste oder eines Tasters simulieren, indem Sie geschweifte Klammern und einen kurzen Tag für die Taste verwenden. Ich werde das also tun. Oder, wenn wir wollen... Ich habe das alles weggewischt - upps - "123". Lassen Sie mich zurückkommen und den Namen der Taste holen. Kommen Sie hierher zurück, holen Sie ihn und klicken Sie ihn an. Wow, Sie sind ein hartgesottenes Publikum, Sie lachen ja gar nicht. Ich denke, das ist ziemlich cool.

Sieht jemand ein Problem mit dem, was ich hier gemacht habe? "SSO". Oh, nun, SSO könnte eine Sache sein, die das Problem hervorhebt... ja, Sie heben das Problem hervor. Was ist daran falsch? Es ist hart kodiert, richtig? Das wollen wir nicht. Aber wir haben die Möglichkeit, Umgebungsvariablen hinzuzufügen, richtig? Ich kann also zurück in meine Konfiguration gehen und sagen: "Hey, ich möchte Umgebungsvariablen hinzufügen." Ups, das ist nicht die richtige Taste. Versuchen wir es mal mit dieser. So, das war's. Und ich kann sagen: "Hey, ich will test_user, und ich will, dass test_user standardmäßig bob ist." Oh, wir werden "bob2" ändern, und dann brauche ich test_userPass, und das soll standardmäßig auf "4567" stehen. Richtig? Wenn ich das nun aktualisiere und in meinen Test zurückkehre, kann ich diese statischen Werte loswerden und sagen: "Hey, ich möchte Cypress.env verwenden und ich möchte, dass du test_user abrufst, und ich möchte, dass du hierher gehst und ich möchte, dass du Cypress.env('test_user_pass) abrufst." Und wenn wir das speichern, vorausgesetzt, ich habe mich nicht vertippt, verwendet es jetzt bob2. Das bedeutet, dass ich in einer anderen Umgebung diese Umgebungsvariablen hinzufügen kann und sie automatisch übernommen werden.

Gut, es gibt noch einen Punkt, den ich kurz erwähnen möchte, und zwar müssen Sie sich für eine Strategie zur Verwaltung des Zustands entscheiden. Auf dieser Folie geht es um den Zustand eines Benutzers, da wir einen Benutzer testen, aber das gilt auch für den Zustand der Anwendung selbst. Eine Strategie besteht darin, dass Sie Anfragen abfangen können. Erinnern Sie sich, dass ich das Abfangen erwähnt habe? Wir könnten also eine Anfrage an wp-login abfangen, diese abfangen und dann statische Informationen über die Cookies und die Sitzungsinformationen zurückgeben. Das ist nett, weil es wirklich schnell ist und ich keine Umgebung haben muss - ich muss keine Datenbank einrichten. Aber beachten Sie, dass er eine Grimasse zieht, weil er Fixtures benötigt. Fixtures sind die statischen Daten, die Sie zurückgeben möchten. Wenn sich die Cookie-Informationen und die Sitzungsinformationen in der Anwendung ändern, muss ich daran denken, zurückzugehen und die statischen Informationen zu aktualisieren, die ich gespeichert habe. Aber es ist auch kein echter End-to-End-Test, richtig? Bei einem End-to-End-Test wollen wir wirklich versuchen, das, was der Endbenutzer erlebt, so realitätsnah wie möglich nachzubilden.

Die nächste Strategie ist also ein statischer Benutzer, bei dem wir in unser System gehen und einen Benutzer erstellen, den wir in unseren Tests verwenden werden. Das ist gut, weil es dann eine echte End-to-End-Sitzung ist, richtig? Wir haben eine Datenbank, wir haben einen echten Benutzer. Aber das bedeutet, dass wir eine Umgebung brauchen, in der wir eine Datenbank anlegen können, und wir müssen die Datenbank einrichten - sei es, dass wir sie aus einem anderen System exportieren und dann dorthin importieren, oder dass wir vielleicht die Installation von WordPress automatisieren und diesen Bereich einrichten. Der Nachteil ist jedoch, dass sich - insbesondere bei WordPress - der Status des Benutzers ändert und in der Datenbank gespeichert wird, wenn er etwas tut, richtig? Dies kann sich auf die Wiederholung des Tests oder auf zukünftige Tests auswirken, da der Status des Benutzers gespeichert ist.

Der letzte Typ ist ein dynamischer Benutzer, bei dem der Benutzer vor jedem Test gelöscht und neu angelegt wird. Dies ist ein echter End-to-End-Test, weil wir jetzt genau die Erfahrung nachbilden, die der Benutzer haben würde. Wir müssen uns nicht um Zustandsmutationen oder "dangling state" kümmern, aber wir müssen jedes Mal den gesamten Abriss und Neuaufbau des Zustands mit der Datenbank durchführen, was bedeutet, dass es ein bisschen langsamer und komplexer ist.

Für den heutigen Tag werde ich - wenn ich die richtigen Schlüssel finde - DDEV einen Benutzer für mich anlegen lassen, und zwar bob2. Ich werde dieses Passwort nehmen, damit wir einen echten Benutzer haben. Kopieren Sie das, kommen Sie zurück zu Cypress, ich schließe meinen Test, schließe Cypress, und komme zurück. Und bevor ich es starte, exportiere ich diese Werte. Ich exportiere also test_user und verwende jetzt bob2 und das Passwort. Starten wir nun Cypress neu. Starten wir unsere End-to-End-Tests neu.

[Pause für Aktion]

Wenn wir jetzt zum Autorisierungstest gehen, TA-DA! haben wir einen echten Benutzer. Sie können überprüfen, ob das funktioniert hat, denn wenn Sie nicht den richtigen Benutzernamen und das richtige Kennwort eingeben, kehren Sie zur Anmeldung zurück, aber es wird eine 200 gesendet, was technisch gesehen bedeutet, dass der Test erfolgreich war. Wie können wir also überprüfen, ob das funktioniert hat? Schnappen Sie sich den Benutzernamen. Ich gehe also hier oben hin, benutze den Picker und sage: "Hey, gib mir das." Ich nehme das, gehe zurück in meinen Test und sage: "Okay, nachdem du darauf geklickt hast", es wird automatisch gewartet, bis die nächste Seite geladen ist, dann kann ich sagen: "Nimm das." Ich werde nach unten gehen, weil es ein wenig lang wird, und ich werde sagen, sollte enthalten, und dann werde ich zurückgehen und sagen Cypress.env('test_user'). Wenn ich es richtig schreibe. Wenn ich das jetzt speichere, führen wir den Test aus. Juhu, da ist er. Das ist unsere Assertion. Sie ist schön und grün. Wir haben bestanden. Alles klar? Sind alle so weit zufrieden?

Okay, sagen wir, wir wollen den Test erweitern. Wir haben gerade den zweiten Test geschrieben, aber wir wollen ihn erweitern. Schauen Sie sich das nicht an; vergessen Sie, dass Sie das gesehen haben. Tut mir leid, ich bin zu weit gegangen. Also, wir wollen diesen Test erweitern. Sagen wir, wir möchten einen zweiten Test durchführen, bei dem wir einen benutzerdefinierten Beitragstyp hinzufügen können. Vielleicht haben sie eine benutzerdefinierte Rolle - dieser Benutzer hat eine benutzerdefinierte Rolle - und wir wollen überprüfen, ob sie diesen Beitragstyp erstellen und sehen können. Eine Sache, die ich noch nicht erwähnt habe, ist, dass Cypress beim Ausführen jedes Tests den Inkognito-Modus oder den privaten Modus für jeden Test verwendet. Das bedeutet, dass eine Instanz aufgerufen, ausgeführt, beendet und geschlossen wird. Das heißt, wenn ich versuche, hierher zu gehen und cy.visit auszuführen und dann vielleicht etwas wie wp-admin/edit.php aufzurufen, was wird dann passieren? Es wird erfolgreich sein und eine 200 erhalten, aber es wird nicht an die richtige Stelle gehen, richtig? Soll ich also diesen ganzen Inhalt kopieren und in den nächsten Test einfügen?

[Publikumsreaktion] "Nein."

Okay, das Kopfschütteln ist die richtige Antwort. Richtig, stattdessen... Erinnern Sie sich, dass ich sagte, dass wir einen Haufen unterstützender Dateien erhalten? Eine dieser Dateien heißt "commands.js". Damit können wir unsere eigenen benutzerdefinierten Befehle erstellen. Ich kann also Cypress.commands.add() verwenden. Der erste Parameter ist der Name der Methode, des neuen Befehls, den Sie aufrufen wollen, also sage ich "wplogin". Der zweite Parameter ist - raten Sie mal, was der zweite Parameter ist? Eine Callback-Funktion, richtig? Rückruf-Funktion. Und dann können wir hier drinnen diesen Code einfügen.

Möchte ich diese Umgebungsvariablen immer noch verwenden? Wahrscheinlich schon. Aber vielleicht? Was ist, wenn ich mehrere Benutzer testen will? Stattdessen könnte ich sagen: "In Ordnung, die Callback-Funktion akzeptiert einen Benutzernamen und ein Passwort." Jetzt kann ich hier reingehen und das löschen. Dann wird das... [Pause für Aktion]

Alles, so geht's. Und sagen: "Benutzername, Benutzername hier." Oh, das war das Passwort, tut mir leid, das wird nicht funktionieren. Versuchen Sie es mit "Passwort", los geht's. Und dann, hier unten, "Benutzername". In meinem Authentifizierungstest kann ich dann cy.wplogin() sagen und dann - mit dem falschen Schlüssel - Cypress.env('test_user') und Cypress.env('test_user_pass') übergeben. Ein Nachteil von Live-Demos ist, dass ich kein schneller Tipper bin. So, und jetzt wollen wir mal sehen, ob das funktioniert hat. Das ist unser Auth-Test. Der erste sagte: "Ja, sieh mal, er hat den ganzen Code ausgeführt, und wir..." Oh, das ist ein guter Zeitpunkt, um es dir zu zeigen - erinnerst du dich an die Zeitreise? Hier sind all die verschiedenen Zustände. Sie können sehen, dass die Eingabe des Benutzernamens erfolgt ist, dass er eingegeben wurde, dass die nächste Eingabe gelöscht wurde und dass das Passwort eingegeben wurde. Klicken Sie auf "Absenden", "Folgen", "Folgen", "Folgen", bis zum Ende, und da ist unsere Behauptung.

Super. Nun gut, nehmen wir an, ich möchte den nächsten Test machen. Soll ich diese Zeile kopieren und einfügen?

[Publikumsreaktion] "Nein."

Nein. Genau wie bei WordPress gibt Cypress Ihnen Hooks. Einer dieser Haken besteht darin, vor jedem Test etwas auszuführen. Raten Sie mal, was es braucht? Ups, das ist zu viel - eine Callback-Funktion. Ja, alles ist ein Rückruf. Und jetzt kann ich diese Zeile nehmen - eigentlich sollten wir es so machen; sie läuft an der Seite meines Bildschirms, ich kann sie nicht sehen -, sie von dort abschneiden und sie hier oben einfügen. Wenn ich das jetzt ausführe, sehen Sie, dass es nicht nur bei der ersten, sondern auch bei der zweiten Zeile geklappt hat. Und jetzt, am Ende, hat es tatsächlich die Bearbeitungsseite gemacht.

Gut, aber es geht zum Formular, holt die Elemente und gibt die Informationen jedes Mal ein. Zwei Tests sind wahrscheinlich keine große Sache. Aber was ist, wenn wir 15 Tests haben? Wäre es nicht schön, wenn wir stattdessen... das wollte ich Ihnen vorhin zeigen - wenn wir die Sitzungsdaten speichern könnten? Ja, genau. Wir haben also diese Möglichkeit in Cypress. Es nimmt eine Sitzung, die wir erstellt haben, und speichert sie basierend auf einer ID. Dazu braucht es vier Argumente. Ich wette, Sie können sich denken, was ein paar davon sind. Das erste ist eine ID, mit der wir diese Sitzung identifizieren wollen. Das nächste ist ein Callback, mit dem wir unseren Einrichtungscode ausführen. Die dritte Option ist ein weiterer Callback, mit dem wir, wenn wir eine Sitzung wiederherstellen, die Sitzung validieren können, und wenn die Validierung fehlschlägt, wird der Setup-Callback erneut ausgeführt. Und die vierte Option ist, ob wir diese gespeicherte Sitzung für weitere Spec-Dateien freigeben wollen oder nicht.

Ich werde dies also zu unserem Code hinzufügen. Ich gehe zurück zu den Befehlen, greife mir das alles, schneide es aus und sage cy.session. Ich verwende den Benutzernamen als unsere ID, setze den Callback und füge unsere Informationen wieder ein. Wenn ich nun diese Tests speichere und ausführe, heißt es beim ersten Mal: "Hey, ich muss die bobby2-Sitzung erstellen", und es läuft durch all diese Schritte, genau wie zuvor. Aber beim zweiten Mal heißt es: "Ich brauche die bobby2-Sitzung, aber ich werde sie wiederherstellen", so dass dieser Prozess nicht wiederholt werden muss.

Das ist sehr wichtig, denn viele von Ihnen werden wahrscheinlich Tests von authentifizierten Sitzungen durchführen müssen. Der Grund dafür ist, dass Cypress zwischen Version 12 und Version 13 eine Funktion eingeführt hat, die das Speichern von Sitzungsinformationen erheblich vereinfacht hat. Wenn Sie im Internet nach der Vorgehensweise suchen, finden Sie oft veraltete Artikel und Blogbeiträge, die nicht mehr aktuell sind.

In den letzten Minuten möchte ich Ihnen einige Best Practices an die Hand geben, die Sie beim Schreiben dieser Tests beachten sollten. Erstens: Wenn Sie ein Anmeldeformular nicht testen müssen, brauchen Sie Chrome nicht in den Prozess einzubeziehen. Behandeln Sie es stattdessen programmatisch. Das heißt, anstatt die Seite aufzurufen, führen Sie einen POST an die Seite wp-login.php aus. Alles andere bleibt gleich, einschließlich des Methodennamens und der Sitzungseinrichtung, aber ich übermittle diese Informationen programmatisch, so dass ich Chrome nicht aufrufen muss.

Der nächste Punkt, den es zu beachten gilt, ist einer der Nachteile bei der Verwendung von Cypress, vor allem, wenn Sie bereits JavaScript-Entwickler sind: Sie können die Rückgabewerte eines Cypress-Befehls nicht einer Variablen oder Konstanten zuweisen; Sie können nur über Closures und Aliase auf diese Rückgabewerte zugreifen. Manche Leute finden das unangenehm, aber das ist der Kompromiss für die Geschwindigkeit. Um schnell in Cypress einsteigen zu können, müssen Sie sich an die Vorgaben halten.

Ich habe es bereits erwähnt, aber versuchen Sie, den Zustand vor jedem Test festzulegen, so dass jeder Test zu jedem Zeitpunkt unabhängig ausgeführt werden kann. Versuchen Sie außerdem, die Verwendung von spröden Selektoren zu vermeiden. IDs und Klassen können sich ändern, und sogar die Position eines Elements kann sich ändern, ohne dass dies sichtbar ist. Cypress empfiehlt, wenn möglich Datenattribute zu verwenden und eindeutige Datenattribute festzulegen, die sich nicht ändern, um sicherzustellen, dass Ihre Tests nicht brüchig sind.

Okay, Quizfrage: Wer kann End-to-End-Tests definieren? Irgendjemand? Das war eines meiner Ziele, und ich möchte nicht daran scheitern! Irgendjemand!

[Zuhörer]: Testen von Ende zu Ende

Testen Sie alle Teile, vom Anfang bis zum Ende! Wir werden versuchen, einen Benutzer zu imitieren, der die Pfade unserer Anwendung durchläuft, und dann anhand dessen, was er getan hat, überprüfen, ob unsere Anwendung korrekt reagiert hat. Kann mir jemand einen Vorteil von End-to-End-Tests nennen?

[Teilnehmer aus dem Publikum]: Zeit sparen!

Zeit sparen! richtig? Viel schneller. Im Grunde genommen macht man manuelle Tests, aber viel schneller, weil der Computer viel schneller ist als man selbst. In Ordnung, ist jeder damit vertraut, was Cypress ist, wie man es installiert, wie man es konfiguriert - man öffnet es ja gerade - und wie man vielleicht seinen ersten Test schreibt?

[Teilnehmer aus dem Publikum]: Ich habe eine Frage.

Ja, klar.

[Teilnehmerin aus dem Publikum]: Also im Code haben Sie Cypress mit einem Großbuchstaben und dann cy geschrieben. Was ist der Unterschied?

Cypress bezieht sich auf die globale Anwendung, und Sie verwenden es für den Zugriff auf Umgebungsvariablen und andere globale Einstellungen. Für andere Befehle verwenden Sie cy innerhalb Ihrer Tests. In der Dokumentation finden Sie weitere Einzelheiten.

Fühlt sich jeder beim Schreiben des ersten Tests wohl? Fühlen Sie sich einigermaßen sicher mit den besten Strategien für das Schreiben Ihrer zweiten und dritten Tests?

Jetzt möchte ich Ihnen ein reales Szenario zeigen, damit Sie eine Vorstellung davon bekommen, wie das alles zusammenpasst. Einer der Gründe, warum ich Cypress so schätze, ist, dass das Unternehmen eine gut dokumentierte und stabile GitHub-Aktion hat. Das bedeutet, dass Cypress in meinen GitHub-Workflows automatisch alle End-to-End-Tests ausführen kann, wenn ich eine Pull-Anfrage erstelle. Bei Platform haben wir auch eine GitHub-Integration. Wenn Sie eine Pull-Anfrage erstellen, wird der Code an uns gesendet. Wir klonen dann Ihre Produktionsumgebung in eine isolierte Umgebung mit diesem Pull-Request-Code, rufen die geklonte Umgebung auf, erzeugen eine ephemere URL und senden diese URL zurück an GitHub.

Wenn ich die Cypress-Aktion ausführe, kann ich die URL der geklonten Produktionsumgebung mitgeben. Wenn ich also die End-to-End-Tests ausführe, entsprechen sie genau dem, was ich in der Produktionsumgebung erwarten würde. Das stärkt das Vertrauen in den Code vor der Bereitstellung.

Ich werde Ihnen das in der Praxis zeigen. Ich habe eine Pull-Anfrage für meine Produktionsseite geöffnet, und ganz unten bei den Prüfungen kann ich sehen, dass die Plattformintegration abgeschlossen ist und die PR-Umgebung bereitgestellt wurde. Wenn ich sie öffne, sehe ich einen Klon meiner Produktionsumgebung, der der Pull-Anfrage zugewiesen ist. Ich sehe auch, dass meine End-to-End-Tests fehlgeschlagen sind. Ein Blick in die Details zeigt, dass sechs Tests bestanden wurden und einer fehlgeschlagen ist. Wenn Sie Ihr Projekt mit Cypress Cloud integrieren, können Sie die Tests wiederholen, wenn etwas fehlschlägt. Sie können den Test erneut ausführen, die durchgeführten Schritte auf der linken Seite sehen und den Zustand der Anwendung auf der rechten Seite anzeigen. In diesem Fall ist der Test fehlgeschlagen, weil das Papierkorbsymbol fehlte, wodurch ein Benutzer seinen Beitrag nicht löschen konnte. Jetzt kann ich die Testwerkzeuge verwenden, um das Problem zu beheben.

Gut, ich denke, wir haben 15 Minuten Zeit für Fragen. Hat jemand eine?

FRAGEN UND ANTWORTEN

Bitte beachten Sie: Aufgrund der schlechten Audioqualität handelt es sich um Vermutungen

[Zuhörer]: Wenn Sie entscheiden, was Sie Ende-zu-Ende testen wollen, testen Sie dann immer eine Art von Frontend-Funktionalität? oder Wie entscheiden Sie allgemein, was Sie testen wollen?

[Paul]: Dieses Tool ist für webbasierte Anwendungen gedacht, die in den meisten Fällen innerhalb einer Weboberfläche liegen werden. Es gibt andere Tools, die direkt API-Tests durchführen können. Sie können API-Tests vortäuschen, wenn Sie das wirklich brauchen, aber dafür ist dieses Tool nicht gedacht. Wenn Sie das Verhalten eines Benutzers durch die Anwendung nachahmen und eine Funktion validieren müssen, dann verwenden Sie dieses Tool.

[Wenn man mit WordPress arbeitet, ändert man oft viel am Kern, ist es also hilfreich, oder gibt es ein Basispaket, um den Kern zu testen, bevor man die einzelnen Teile der Anwendung testet? Gibt es eine Bibliothek, auf die man zurückgreifen kann, um sicherzugehen, dass das reguläre WordPress zuerst funktioniert und dann unsere aufgeschichteten Funktionen zu testen?

[Paul]: Core ist zu Playwright gewechselt, also haben sie die Playwright-Tests; den Cypress-Test haben sie vor Jahren aufgegeben, also leider "nein". Ich würde sagen, wenn das ein entscheidendes Teil ist, dann würde ich mir Playwright ansehen und dann haben Sie deren Test, den Sie ausführen können. Es ist ja nicht so, dass Playwright schlecht ist. Ich möchte nicht, dass jemand denkt, dass man es nicht benutzen sollte. Es ist nur neu; es ist erst ein paar Jahre alt, die Dokumentation ist da, aber nicht so umfangreich. Wenn das also eine wichtige Funktion ist, würde ich sagen, schauen Sie sich Playwright an und dann haben Sie deren Test, den Sie durchführen können.

[Teilnehmer aus dem Publikum]: Nun, ich meine, ich weiß nicht, ob man wirklich alles testen muss, was der Kern testet. Sie wissen schon, nur ein Überblick. Zum Beispiel, oh, WordPress ist hier, weißt du, was ich meine?

[Paul]: Das ist ein anderes Beispiel. Wir verwalten die Ein-Klick-Deployments, nicht wahr? Wir verwalten diese und ich habe alle Updates für diese automatisiert. Und als Teil des Tests führe ich eine kurze Überprüfung der Kernfunktionen durch, um sicherzustellen, dass die wichtigsten Funktionen vorhanden sind, so dass keiner unserer benutzerdefinierten Codes eine der Kernfunktionen negativ beeinflusst hat. Also, ja. Ich meine, ich habe das getan und es gibt keinen Grund, warum Sie das nicht auch tun sollten.

[Teilnehmer aus dem Publikum]: Können Sie mit diesem Klon interagieren? Wenn Sie Ihre eigenen manuellen Tests durchführen wollen oder so?

[Paul]: Nein, das kann man nicht. Es wird der Status jedes einzelnen Klons gespeichert, aber man kann nicht klicken und zusätzliche Dinge tun.

[Teilnehmer aus dem Publikum]:
Sie können sich nicht als Sie selbst anmelden und Dinge ausprobieren? Sie müssten einen Test dafür schreiben?

[Anderer Teilnehmer aus dem Publikum]:
Ich glaube, Sie fragen nur: Kann man als Mensch die PR-Umgebung der Plattform besuchen?

[Ursprüngliches Mitglied des Publikums]:
Ja.

[Paul]: Oh, absolut! Ich dachte, Sie meinten die Screenshots der Testumgebung, die wir gesehen haben, die Cypress uns gezeigt hat, um uns den Test zu zeigen.

[Teilnehmer aus dem Publikum]: Nein, nein. Ich meinte den Klon mit dem neuen Code. Es wäre cool, damit interagieren zu können.

[Paul]: Ja, das können Sie auf jeden Fall tun. Sie können das sogar nutzen, um Ihren Test zu schreiben. Wenn Sie den Test durchführen, können Sie damit alle Schritte aufzeichnen, die Sie unternehmen. Tut mir leid, ich habe nicht verstanden. Sonst noch jemand?

[Teilnehmer aus dem Publikum]: Habt ihr irgendwelche visuellen Regressionen in eurem Stack, die ihr mit diesen Tools durchführt?

[Paul]: Also das ist ein separates Tool, das ich benutze, und ich werde den Namen vergessen... Es hat ein Affengesicht... oh, ich habe den Namen für visuelle Regressionstests vergessen... und ich werde mich in etwa zwei Sekunden, nachdem ihr alle gegangen seid, daran erinnern, wie der Name lautet... Es gibt ein Open-Source-Tool - Backstop! Backstop, wir benutzen Backstop für visuelle Regressionstests, um sicherzustellen, dass es keine visuellen Regressionen gibt. Falls Sie mit visuellen Regressionstests nicht vertraut sind: Sie geben dem Programm eine Produktionsseite oder eine Basisseite, die korrekt sein sollte, und dann geben Sie ihm Ihre Testumgebung, Ihre Entwicklungs-, Staging-, PR- oder sonstige Umgebung. Es macht Screenshots von den Stellen, die Sie identifizieren, und vergleicht sie. Wenn der Unterschied größer ist als ein von Ihnen festgelegter Prozentsatz, dann wird dies als falsch oder als Regression gekennzeichnet. Ja, das kann man auf jeden Fall einbauen, und ich würde Sie ermutigen, so viele dieser automatisierten Tests wie möglich einzubauen, um die Anzahl der Arbeitsstunden zu reduzieren, die Sie in diese Dinge investieren müssen. Ich weiß, dass man im Hochschulbereich nicht die Zeit hat; man bekommt nur mehr Verantwortung, nicht mehr Leute. Daher ist es umso besser, wenn man diese Dinge automatisieren kann. Gibt es weitere Fragen?

[Teilnehmer aus dem Publikum]: Jemand hat SSO erwähnt. Wir haben behat schon vor Jahren ausprobiert und hatten Probleme, uns in WordPress einzuloggen, um irgendwelche internen Dinge zu tun. Wir konnten zwar das Frontend nutzen, aber nicht das Einloggen, Posten, also...

[Paul]: Angenommen, Sie haben einen Testbenutzer im Single-Sign-On-System, bei dem Sie das Passwort irgendwo hinterlegen können, um es tatsächlich zu verwenden, dann sollte es möglich sein. Ich sehe keine Probleme mit SSO voraus. Ich kann nicht sagen, dass ich es kürzlich mit SSO getestet habe, aber es sollte funktionieren.

[Ein anderer Teilnehmer aus dem Publikum]: Wir haben das nicht mit Cypress gemacht, aber wir haben es mit Puppeteer mit AWS gemacht. Das Gleiche, und ja... es funktioniert tatsächlich auf die richtige Weise.

[Paul]: Das ist ein guter Punkt. Ob Sie nun Cypress oder Playwright verwenden, die Konzepte sind im Grunde alle gleich. Es geht nur um die Besonderheiten, wie man den Test schreibt, richtig? Wenn man also mit Cypress anfängt und feststellt, dass das für uns nicht funktioniert, hat man nicht wirklich etwas verloren, außer vielleicht ein bisschen Zeit, um sich mit den Besonderheiten vertraut zu machen. Aber man kann dieselbe Testideologie nehmen und sie auf das nächste Produkt übertragen. Gibt es noch weitere Fragen? Sind alle bereit für die Mittagspause?

(Raummoderator): Es ist eine online. Eine Frage online.

[Paul]: Oh, also der Abriss und die Einrichtung. Ja, also im App-Status. Als ich erwähnte, dass ich die Benutzer für WordPress Core teste, musste ich Funktionen in Cypress schreiben, die sich mit dieser Umgebung verbinden und den dynamischen Benutzer erstellen, so wie ich es getan habe. Zuerst wird der Benutzer gelöscht, alle Beiträge werden gelöscht, alles über den Benutzer wird gelöscht. Dann wird der Benutzer erstellt, das Kennwort wiederhergestellt, als Cypress-Umgebungsvariable festgelegt und Cypress wieder gestartet. So handhabe ich das also, und Sie müssen ähnlich vorgehen. Sie können es in den GitHub-Aktionen machen, wenn Sie wollen. Es gibt keinen Grund, warum Sie das nicht können, aber da Cypress diese Hooks hat, können Sie einen "before" -Hook machen und sagen, bevor ich irgendeinen dieser authentifizierten Tests ausführe, führe ich all dieses Setup-Zeug oder das "beforeEach" aus, während es bei GitHub-Aktionen hauptsächlich "before" und "after" sein muss.

Ich glaube, das sind alle Fragen, die online gestellt wurden. Gibt es noch weitere Fragen? Auch hier werde ich die restliche Zeit bis Samstag anwesend sein. Sie können mich gerne ansprechen und mir weitere Fragen zu allem stellen. Ich liebe Automatisierung, also wenn es um Testen, DevOps, irgendetwas davon geht, liebe ich es.