How Guru’s Engineers Use Cypress for Better Burn Testing
Benötigen Sie einen besseren Weg, um Burn-Tests durchzuführen? Zwei unserer Frontend-Ingenieure haben einen Weg gefunden, Cypress zu verwenden, um die Art und Weise zu verbessern, wie sie QA handhaben.
Wir sind bei Guru ganz auf Wissensaustausch fokussiert, und wenn wir etwas Neues und Hilfreiches entdecken, wollen wir, dass die Welt es weiß! Unser Engineering-Team nutzt Cypress in ihrem Test- und QA-Prozess. Sie haben eine neue Methode entdeckt, um bessere Burn-Tests durchzuführen, und sie möchten ihren neuen und verbesserten Prozess mit anderen Ingenieuren und Testern teilen.
Im vergangenen Jahr haben wir uns darauf konzentriert, unsere Testabdeckung zu erhöhen – insbesondere durch End-to-End-Tests, die sicherstellen, dass verschiedene Teile unserer Produktflüsse korrekt funktionieren, während wir Code-Updates durchführen. Für diese Art von Tests nutzen wir ein Tool namens Cypress, das das Nutzerverhalten mit unserer Webanwendung und der Google Chrome-Erweiterung simuliert. Dieses Testpaket wird bei jeder Pull-Anfrage ausgeführt, um sicherzustellen, dass neuer Code nichts in unserer Benutzeroberfläche kaputtmacht. Wir möchten auch verhindern, dass Releases stattfinden, wenn unser Cypress-Paket auf unserem Produktionsbranch fehlschlägt.
Was wir bei traditionellem Testing suchen
Ein Problem, mit dem wir zu kämpfen hatten, ist, dass einige unserer Tests fehlschlagen, aber nicht aus Gründen, die mit der Benutzeroberfläche oder dem Code zusammenhängen. Wie hilft uns Cypress in diesen Fällen? Wir lassen Cypress als einen Nutzer agieren, dessen Verhalten wir definieren können. Es gibt mehrere Variablen, die dazu führen könnten, dass Cypress uns ein Versagen mitteilt, aber aus der Perspektive eines Nutzers scheint nichts falsch zu sein.
Zum Beispiel könnte ein Test sagen: „Gehe zu diesem Teil der Webanwendung > Füge eine neue Guru-Karte hinzu > Erwarten, einen Zustand nach der Erstellung zu sehen“. Wenn der Ladezustand zum Erstellen einer Karte eine Millisekunde zu lange dauert und Cypress beginnt, nach dem Zustand nach der Erstellung zu suchen, bevor er da ist, könnte dieser Test fehlschlagen (die meiste Zeit wird dieser Test bestanden). Wenn er einmal bei einer Pull-Anfrage besteht, sind wir in der Lage, Code zu mergen, der manchmal fehlerhaft sein könnte. Aber wir werden nicht wissen, ob er das tut; ein bestandener Test ist keine Garantie dafür, dass der Code korrekt ist.
Diese Art von Situation senkt die Zuverlässigkeit unserer Testabdeckung. Wenn ein Testfehler in unserer Bereitstellungspipeline auftaucht, müssen wir überprüfen, ob es ein Problem mit der Benutzeroberfläche oder mit dem Test ist. Um dies zu beheben, haben wir begonnen, darüber nachzudenken, wie wir erkennen können, ob ein Test möglicherweise fehlerhaft sein könnte, bevor er zu unserem Produktionscode-Branch geht.
Wie Burn-Tests helfen
Einführung in Burn-Tests. Burn-Testing ist ein Verfahren, das verwendet wird, um etwas unter strikteren oder extremen Bedingungen zu testen. Es wird auch manchmal als Lasten- oder Stresstest bezeichnet, je nach Methode oder spezifischem Bereich, der getestet wird.
Bei Guru verwenden wir Burn-Tests als Teil unseres Cypress-Pakets für alle neuen oder modifizierten Tests, die zu unserem Code hinzugefügt werden. Bevor diese Tests zusammengeführt werden können, führen wir sie mehrere Male nacheinander aus und alle müssen bestehen, um zum nächsten Schritt in unserer CircleCI-Baupipeline überzugehen.
Dieser Schritt erfolgt unmittelbar bevor wir das gesamte Cypress-Testpaket ausführen. Der Vorteil dieser Reihenfolge besteht darin, dass, wenn unser Burn-Test-Schritt einen Fehler produziert, wir die gesamte Überprüfung frühzeitig als Fehlgeschlagen markieren können. Das Überspringen des Restes des Pakets ermöglicht es uns, Zeit zu sparen und die Anzahl der Zyklen zu reduzieren, die erforderlich sind, um sicherzustellen, dass neu eingeführte Tests so zuverlässig und fehlertolerant sind, wie wir sie benötigen.
Um die Dateien zu finden, die wir suchen, verwenden wir git diff im aktuellen Branch und geben die Ausgabe als Parameter an ein Tool namens cypress-repeat weiter, das es uns ermöglicht, diese Tests eine angegebene Anzahl von Malen auszuführen, wodurch Burn-Tests effektiv als Schritt in unserem End-to-End-Testpaket hinzugefügt werden.
Das Ergebnis
Diese Anpassung unserer Testpläne hat einige ziemlich solide positive Ergebnisse gebracht. Für uns kann das Hinzufügen von Burn-Tests die Zeit, die benötigt wird, um unzuverlässige Tests zu finden, um bis zu 30 Minuten reduzieren. Es verbessert auch die Reaktionszeit für das Hinzufügen neuer Funktionen. Da die neu hinzugefügten Tests nun zuerst ausgeführt werden, ermöglichen sie es uns, die Stabilität zu überprüfen, bevor wir mit dem Rest des Bauprozesses fortfahren.
Insgesamt erhöht unser anhaltender Fokus darauf, unsere Testprozesse effizienter und robuster zu gestalten, das Vertrauen des gesamten Engineering-Teams in die schnelle Bereitstellung neuer Funktionen. Wir beheben Fehler schneller und arbeiten einfacher über alle unsere Codebasen hinweg. Wir hoffen, dass dieser Beitrag anderen Cypress-Nutzern hilft, bessere Tests zu erstellen, und dass ganze Teams effizienter arbeiten.
Wir sind bei Guru ganz auf Wissensaustausch fokussiert, und wenn wir etwas Neues und Hilfreiches entdecken, wollen wir, dass die Welt es weiß! Unser Engineering-Team nutzt Cypress in ihrem Test- und QA-Prozess. Sie haben eine neue Methode entdeckt, um bessere Burn-Tests durchzuführen, und sie möchten ihren neuen und verbesserten Prozess mit anderen Ingenieuren und Testern teilen.
Im vergangenen Jahr haben wir uns darauf konzentriert, unsere Testabdeckung zu erhöhen – insbesondere durch End-to-End-Tests, die sicherstellen, dass verschiedene Teile unserer Produktflüsse korrekt funktionieren, während wir Code-Updates durchführen. Für diese Art von Tests nutzen wir ein Tool namens Cypress, das das Nutzerverhalten mit unserer Webanwendung und der Google Chrome-Erweiterung simuliert. Dieses Testpaket wird bei jeder Pull-Anfrage ausgeführt, um sicherzustellen, dass neuer Code nichts in unserer Benutzeroberfläche kaputtmacht. Wir möchten auch verhindern, dass Releases stattfinden, wenn unser Cypress-Paket auf unserem Produktionsbranch fehlschlägt.
Was wir bei traditionellem Testing suchen
Ein Problem, mit dem wir zu kämpfen hatten, ist, dass einige unserer Tests fehlschlagen, aber nicht aus Gründen, die mit der Benutzeroberfläche oder dem Code zusammenhängen. Wie hilft uns Cypress in diesen Fällen? Wir lassen Cypress als einen Nutzer agieren, dessen Verhalten wir definieren können. Es gibt mehrere Variablen, die dazu führen könnten, dass Cypress uns ein Versagen mitteilt, aber aus der Perspektive eines Nutzers scheint nichts falsch zu sein.
Zum Beispiel könnte ein Test sagen: „Gehe zu diesem Teil der Webanwendung > Füge eine neue Guru-Karte hinzu > Erwarten, einen Zustand nach der Erstellung zu sehen“. Wenn der Ladezustand zum Erstellen einer Karte eine Millisekunde zu lange dauert und Cypress beginnt, nach dem Zustand nach der Erstellung zu suchen, bevor er da ist, könnte dieser Test fehlschlagen (die meiste Zeit wird dieser Test bestanden). Wenn er einmal bei einer Pull-Anfrage besteht, sind wir in der Lage, Code zu mergen, der manchmal fehlerhaft sein könnte. Aber wir werden nicht wissen, ob er das tut; ein bestandener Test ist keine Garantie dafür, dass der Code korrekt ist.
Diese Art von Situation senkt die Zuverlässigkeit unserer Testabdeckung. Wenn ein Testfehler in unserer Bereitstellungspipeline auftaucht, müssen wir überprüfen, ob es ein Problem mit der Benutzeroberfläche oder mit dem Test ist. Um dies zu beheben, haben wir begonnen, darüber nachzudenken, wie wir erkennen können, ob ein Test möglicherweise fehlerhaft sein könnte, bevor er zu unserem Produktionscode-Branch geht.
Wie Burn-Tests helfen
Einführung in Burn-Tests. Burn-Testing ist ein Verfahren, das verwendet wird, um etwas unter strikteren oder extremen Bedingungen zu testen. Es wird auch manchmal als Lasten- oder Stresstest bezeichnet, je nach Methode oder spezifischem Bereich, der getestet wird.
Bei Guru verwenden wir Burn-Tests als Teil unseres Cypress-Pakets für alle neuen oder modifizierten Tests, die zu unserem Code hinzugefügt werden. Bevor diese Tests zusammengeführt werden können, führen wir sie mehrere Male nacheinander aus und alle müssen bestehen, um zum nächsten Schritt in unserer CircleCI-Baupipeline überzugehen.
Dieser Schritt erfolgt unmittelbar bevor wir das gesamte Cypress-Testpaket ausführen. Der Vorteil dieser Reihenfolge besteht darin, dass, wenn unser Burn-Test-Schritt einen Fehler produziert, wir die gesamte Überprüfung frühzeitig als Fehlgeschlagen markieren können. Das Überspringen des Restes des Pakets ermöglicht es uns, Zeit zu sparen und die Anzahl der Zyklen zu reduzieren, die erforderlich sind, um sicherzustellen, dass neu eingeführte Tests so zuverlässig und fehlertolerant sind, wie wir sie benötigen.
Um die Dateien zu finden, die wir suchen, verwenden wir git diff im aktuellen Branch und geben die Ausgabe als Parameter an ein Tool namens cypress-repeat weiter, das es uns ermöglicht, diese Tests eine angegebene Anzahl von Malen auszuführen, wodurch Burn-Tests effektiv als Schritt in unserem End-to-End-Testpaket hinzugefügt werden.
Das Ergebnis
Diese Anpassung unserer Testpläne hat einige ziemlich solide positive Ergebnisse gebracht. Für uns kann das Hinzufügen von Burn-Tests die Zeit, die benötigt wird, um unzuverlässige Tests zu finden, um bis zu 30 Minuten reduzieren. Es verbessert auch die Reaktionszeit für das Hinzufügen neuer Funktionen. Da die neu hinzugefügten Tests nun zuerst ausgeführt werden, ermöglichen sie es uns, die Stabilität zu überprüfen, bevor wir mit dem Rest des Bauprozesses fortfahren.
Insgesamt erhöht unser anhaltender Fokus darauf, unsere Testprozesse effizienter und robuster zu gestalten, das Vertrauen des gesamten Engineering-Teams in die schnelle Bereitstellung neuer Funktionen. Wir beheben Fehler schneller und arbeiten einfacher über alle unsere Codebasen hinweg. Wir hoffen, dass dieser Beitrag anderen Cypress-Nutzern hilft, bessere Tests zu erstellen, und dass ganze Teams effizienter arbeiten.
Erleben Sie die Leistungsfähigkeit der Guru-Plattform aus erster Hand – machen Sie unsere interaktive Produkttour
