Viele Experten glauben, dass Cypress das Testing weitgehend vereinfacht. Gleb Bahmutov, ein "JavaScript-Ninja", der in seiner früheren Position an der Entwicklung von Cypress mitgewirkt hat, gab ein Webinar über End-to-End-Tests einer Echtzeit-Webanwendung für Chat mit diesem JavaScript-Tool für Frontend-Testing. Eine Zusammenfassung.
Cypress ist ein Open Source Testing Framework, das für End-to-End-Testing von Webanwendungen eingesetzt wird. Es bietet eine Reihe von leistungsstarken Tools für das Echtzeit-Testing von Webanwendungen, mit einer benutzerfreundlichen Oberfläche und der Möglichkeit, alle Aspekte einer Anwendung zu testen – vom Frontend bis zum Backend. Cypress ist bekannt für seine einfache Einrichtung und schnelles, zuverlässiges Testing.
Wie kann man realistisches End-to-End-Testing mit Cypress für eine Echtzeit-Chat-Anwendung durchführen? Diese Frage steht im Mittelpunkt des Online-Vortrags von Gleb Bahmutov. Der "JavaScript-Ninja" ist derzeit Senior Director of Engineering bei Mercari US, war zuvor VP Engineering bei Cypress und hat in seiner Freizeit mehr als 500 Blogbeiträge über Softwareentwicklung geschrieben.
In dem Webinar, dessen Codelastige Folien hier verfügbar sind, geht er auf vier verschiedene Punkte ein, die alle eine andere Perspektive auf deinen Code geben: Mock-App-Code, Mock-Socket-Verbindung, zweite Socket-Verbindung öffnen und gleichzeitig zwei Test-Runner laufen lassen. Die Anwendung, die Bahmutov bespricht, ist eine auf Socket.io basierende Webanwendung für den Chat. Den Code der Anwendung hat er auf GitHub veröffentlicht.
Zunächst einmal stellt Bahmutov die Frage: Funktioniert die Anwendung? "Man kann sie öffnen, jedoch treten schnell Probleme auf. In Wirklichkeit muss man also in jedem Fall testen, was auf automatisierte Weise einfach besser funktioniert. Deshalb schreiben wir heute einen Cypress-Test." Der JS-Guru erklärt, dass ein typischer End-to-End-Test normalerweise dem folgenden Muster folgt: Befehl - Behauptung(en) - Befehl - Behauptung(en).
Weiter zum ersten Test. "In Cypress sieht man wirklich alles, zum Beispiel wie die Anwendung im echten Browser aussieht, den Benutzernamen und so weiter. Um die Frage "Funktioniert die App wirklich?" zu beantworten, müssen wir uns zunächst fragen, ob ein zweiter Nutzer, der am Chat teilnimmt, meine Nachrichten sehen kann und umgekehrt. Schließlich kann es sein, dass die App die Nachrichten zwar spiegelt, aber nicht sendet."
Bahmutov weicht kurz ab und erklärt, dass das "Problem" bei dieser Art von Testassistenten darin besteht, dass sie irgendwo eine Grenze ziehen müssen: Welcher Teil soll getestet werden und welcher nicht? Er fährt fort: "Von Cypress aus können wir uns mit einem Server von Socket.io verbinden und als zweiter Benutzer agieren. Ein normaler Test wird auf der Seite ausgeführt, ein anderer Teil des Codes verbindet sich mit dem Socket-Server und verhält sich wie ein zweiter Benutzer. Es ist außerdem möglich einen weiteren Cypress Test-Runner zu öffnen und zwei Browser miteinander reden zu lassen."
"Beginnen wir mit etwas Einfachem: Stub-Anwendungscode. Du kannst eine Klasse oder ein Objekt im Anwendungscode erstellen und dieses Anwendungsobjekt für den Test freigeben. Vom Test aus kannst du dann das Anwendungsobjekt ausspionieren und eingehende Nachrichten testen." Bahmutov zeigt, dass die App UI-Nachrichten anzeigt, die im Anwendungscode eingehen, die Seite zeigt dann die Nachrichten an.
Es wurde nun bestätigt, dass der Anwendungscode bis hin zum Socket funktioniert, nur die Socket-Befehle könnten falsch sein. "Um das zu testen, kannst du einen Mock-Websocket verwenden. Dazu musst du den Prod-Websocket gegen den Mock-Socket austauschen." Bahmutov weist darauf hin, dass die Intercept-Funktion von Cypress hier sehr hilfreich ist. Als Nächstes wird der Mock-Socket in den iFrame der Anwendung injiziert. "Wir haben jetzt überprüft, dass die Socket-API innerhalb der Anwendung funktioniert. Mit anderen Worten: Der UI-Code, der Zwischencode und der Websocket.
Auch wenn die Socket-API innerhalb der Anwendung funktioniert, kann es sein, dass der Server defekt ist. "Während des Tests wollen wir die Seite überprüfen, die Benutzeroberfläche durchgehen, den zweiten Benutzer verbinden und simulieren, dass er antwortet und die Nachrichten 'abhört', indem er sich mit demselben Server verbindet." Bahmutov erklärt, wie das funktioniert, und gibt einen Tipp: Die Verbindung für den zweiten Benutzer solltest du außerhalb der Browserseite herstellen, denn so kannst du problemlos eine zweite, separate Verbindung zum Server herstellen.
Wie kannst du zwei Cypress-Instanzen nebeneinander laufen lassen? Dafür brauchst du zwei separate Specs, die beide ausschließlich über die Benutzeroberfläche der Seite laufen. Wahrscheinlich, so erklärt der Testexperte, musst du dafür separate Cypress-Konfigurationsdateien erstellen, da du zwei Instanzen gleichzeitig betreibst. Außerdem muss das NPM-Modul parallel installiert werden.
Bereits auf den ersten Blick weist diese Methode einige Schwächen auf. Zum Beispiel warten die Testinstanzen von Cypress nicht wirklich auf die anderen; sie sind mehr oder weniger blind füreinander. Du willst also in der Lage sein, zu steuern, wie die beiden Test-Runner den Test ausführen. Um die Test-Runner zu synchronisieren, kannst du ein separates Socket.io erstellen. Dabei musst du nur zwei Befehle implementieren: Checkpoint und auf Checkpoint warten. Als Nächstes musst du den Server von Socket.io synchronisieren und die Plugin-Datei von Cypress implementieren.
Bahmutov erklärt, dass der erste Test-Runner die Seite besucht, den Namen festlegt und den Server überprüft, anschließend tritt der erste Benutzer dem Chat bei. Nun muss der zweite Benutzer zum Chat hinzugefügt werden. Er wartet dann auf den Checkpoint, der bestätigt, dass der zweite Benutzer hinzugefügt wurde. Danach prüft der erste Test-Runner, ob der zweite Benutzer tatsächlich da ist. Dieser muss dann eine Nachricht posten, damit du sehen kannst, ob diese Nachricht sichtbar ist.
Die zweite Spec-Datei legt fest, dass der erste Benutzer den Checkpoint zuerst erreichen muss. Dann wird überprüft, ob die Nachricht vom ersten Benutzer kommt. Der erste Test-Runner wartet derweil auf diesen Checkpoint. Etwas zusammengefasst sieht so die erste Runde der Prüfung aus. Bahmutov: "Mit anderen Worten wird also gestartet, dann gewartet, dann kommen die Nachrichten aus der zweiten Testrunde, es wird verbunden, es wird gewartet und dann wird die Nachricht schnell übermittelt. Bei der zweiten Testrunde geht es viel schneller: Es wird verbunden, Checkpoint, Nachricht gesehen und fertig. Die beiden Test-Runner kommunizieren immer miteinander und warten aufeinander, um sicherzustellen, dass alles in der richtigen Reihenfolge abläuft."
"Was ist also besser?", schließt Bahmutov sein Webinar ab. "Ich habe vier verschiedene Möglichkeiten zum Testen von Code aufgezeigt: Stub-App-Code, Websocket-Mocking, damit du nie einen Server von Socket.io aus starten musst, als zweiter Benutzer, der über eine von der Seite isolierten Verbindung zu Socket.io agiert, und schließlich zwei nebeneinanderlaufende Test-Runner, die ebenfalls als zweiter Benutzer agieren. Meiner Meinung nach ist es viel besser, als zweiter Benutzer zu agieren, ohne den kompletten Test-Runner zu starten. Denn letztendlich ist das bereits ein vollständiger End-to-End-Test."
"Der zweite Browser kommuniziert genauso, wie wir über eine Verbindung zu Socket.io kommunizieren würden. Wir kommunizieren nur über eine öffentliche API, ohne etwas privilegiertes gemacht zu haben, denn das war gar nicht nötig." Außerdem ist der Test immer noch sehr schnell, so Bahmutov. "Weniger als zwei Sekunden, um sich auf beiden Seiten zu verbinden, die Seite zu laden, ein paar Nachrichten auszutauschen und schließlich zu bestätigen, dass der Socket-Server funktioniert, die Seite angezeigt wird und dass die Seite Dinge sendet. Genau aus diesem Grund ist dies meine Lieblingsmethode, um Echtzeit-Chat-Anwendungen zu testen."
Du willst tiefer in die Materie eintauchen? Bahmutov hat drei Blogbeiträge geschrieben, die sich ausführlich mit diesem Thema befassen: Teste eine socket.io Chat-Anwendung mit Cypress, führe zwei Cypress Test-Runner gleichzeitig aus und synchronisiere zwei Cypress-Runner über Checkpoints.
Auf der Suche nach IT Development & Testing Professionals? Dank unseres starken Netzwerks an Expert:innen hilft Spilberg weiter. Erfahre mehr über IT-Personaldienstleistungen für Unternehmen.
Gib deiner Karriere einen Boost! Spilberg ist der Partner an deiner Seite bei deiner Suche nach einem neuen Job oder Auftrag. Erfahre mehr über die Möglichkeiten und finde dein Match.