Postman-Tests und wie man sie in Bamboo Build und Deployment einbezieht

Das Schreiben von Komponententests, die sicherstellen, dass einzelne Abschnitte einer Anwendung oder eines Dienstes korrekt ausgeführt werden, ist ein Prozess, der tief in den Arbeitsabläufen der meisten Entwickler verwurzelt ist. Eine andere Form des Testens, die in Ihre Projekte wohl schwieriger einzubeziehen ist, sind Integrationstests. Mithilfe von Integrationstests können Sie sicherstellen, dass alle verschiedenen Codeeinheiten, aus denen Ihre Anwendung besteht, problemlos zusammenarbeiten können. Dies beinhaltet in der Regel das Testen einer bereitgestellten Version Ihres Codes. Aus diesem Grund werden Integrationstests im Allgemeinen als zeitaufwändig und schwierig zu erstellen empfunden. Ein sehr nützliches Tool, das Ihnen bei der Erstellung von Integrationstests helfen kann, ist Postman.

Postman bietet Entwicklern eine Reihe von Tools, die jede Phase des API-Lebenszyklus unterstützen. Der häufigste Anwendungsfall für Entwickler besteht darin, eine API zu debuggen, die kürzlich geändert oder defekt wurde, indem eine Anfrage an den betreffenden Endpunkt gesendet wird. Obwohl dieses Beispiel für ein Entwicklungsteam sicherlich einen Zweck erfüllt, ist es nur ein kleiner Ausschnitt der vollen Vorteile, die durch die Verwendung von Postman realisiert werden können. Eine weitere sehr leistungsstarke, aber wenig genutzte Funktion in den Tools von Postman ist die Möglichkeit, eine Sammlung von Tests zu erstellen und automatisch auszuführen.

Hol Postman her.

Postman-Tests

Eine typische Anfrage an ein lokal gehostetes Backend, das die Postman-Desktop-Anwendung verwendet, könnte ungefähr so aussehen:

Diese Anfrage ist überhaupt nicht komplex, sie ist sogar so einfach wie es nur geht, aber sie erfüllt ihre Aufgabe, mit dem lokal gehosteten Backend zu kommunizieren und eine Antwort zurückzugeben. Mit Postman können wir mit wenigen Codezeilen elegante Tests für unsere Endpunkte erstellen. Nehmen wir zum Beispiel an, wir möchten einen Test für den oben angegebenen Endpunkt erstellen und sicherstellen, dass alle an ihn gerichteten Anfragen einen 200 HTTP Statuscode. Alles was wir tun müssen, ist den Tab „Tests“ der Postman-Anfrage aufzurufen und mit dem Schreiben des Tests zu beginnen.

Auf der rechten Seite des Test-Tabs befindet sich eine Liste von Links, die Code generieren, um das Testen mit Postman ein wenig zu vereinfachen. Die Postman-Testsuite enthält eine Reihe nützlicher Funktionen wie das Einrichten von Umgebungsvariablen und globalen Variablen zur Verwendung in nachfolgenden Anforderungstexten, das Konvertieren des Antwortinhaltstyps und das Einrichten von Antwortobjektdefinitionen zur automatischen Validierung. Weitere Informationen zur Syntax von Postman-Tests und wie man sie erstellt finden Sie hier.

Wenn wir diesen Test fortsetzen, senden wir die Anfrage erneut und stellen sicher, dass unser Test erfolgreich ist.

Jetzt, da wir mit unserem neu erstellten Test zufrieden sind, können wir unsere Anfrage zusammen mit dem Test in einer Postman-Sammlung speichern. Mithilfe von Sammlungen können Sie Anfragen in logische Gruppierungen zusammenfassen. Diese Sammlungen können dann mit anderen Entwicklern geteilt werden, indem gemeinsam nutzbare Links verwendet werden oder indem die Sammlung in eine JSON-Datei exportiert wird, die dann auf beliebige Weise geteilt werden kann. Wir behalten die Testsammlungen gerne in der Quellcodeverwaltung, sodass jeder Entwickler einen zentralen Ort hat, von dem aus er die Tests abrufen kann. Wir verwenden auch Links, die geteilt werden können, um Sammlungen mit unseren Produkt- und Testteammitgliedern zu teilen. Auf diese Weise können wir Mitarbeitern, die keine Techniker sind, die Möglichkeit bieten, unsere Endpunkte in der Entwicklungsumgebung schnell zu testen, ohne dass Code ausgecheckt werden muss oder sperrige Server, die lokal ausgeführt werden, erforderlich sind.

Postman-Umgebungen

Bevor Sie mit der Erstellung zahlreicher Anfragen und Tests fortfahren, könnte es hilfreich sein, zu verstehen, wie Umgebungen in Postman funktionieren. Im Wesentlichen ermöglichen sie es Ihnen, eine Reihe von Schlüssel- oder Wertepaaren zu speichern, die in Anfragen und Tests verwendet werden können. Lesen Sie hier mehr über sie.

Einer der wichtigsten Punkte, die es zu beachten gilt, ist, dass Umgebungen auf die gleiche Weise wie Sammlungen geteilt werden können.

Lokales Ausführen einer Postman-Sammlung

Vor diesem Hintergrund können wir jetzt den Prozess der Erstellung von Anfragen und Tests für alle Endpunkte unseres Servers wiederholen. Es wird empfohlen, Tests zu erstellen, die eine Vielzahl von Anforderungen abdecken. Erstellen Sie beispielsweise einen Test, der sicherstellt, dass einer der Endpunkte einen Text mit bestimmten Datenfeldern zurückgibt. Sobald der Satz von Anfragen mit ausgezeichneten Tests gefüllt ist, konfigurieren Sie Postman so, dass diese Tests alle zusammen als Sammlung ausgeführt werden.

Um eine Sammlung auszuführen, suchen Sie den Test- „Runner“, der sich in der oberen linken Ecke befindet.

Wählen Sie hier die Sammlung und alle für diese Sammlung erstellten Umgebungen aus. Führen Sie als Nächstes die Sammlung aus. Wenn alles gut geht, zeigt ein grüner Kreis die Anzahl der bestandenen Tests an. Weiter unten im Fenster werden detaillierte Informationen zu einzelnen Tests und Anforderungen angezeigt, z. B. die Dauer jeder Anfrage und welche Assert-Anweisungen erfolgreich waren.

Integration dieser Sammlungen in Bamboo Build/Deployment

Wäre es angesichts dieser großartigen Testreihe für diese Endpunkte nicht schön, sie in den Bau- und Bereitstellungsprozess von Bamboo integrieren zu können? Insbesondere wäre es ziemlich cool, eine Postman-Sammlung gegen eine Bereitstellung auszuführen, um sicherzustellen, dass die Codeänderungen in der realen Welt funktionieren. Nun, es gibt einige schlechte und einige gute Nachrichten. Leider werden Postman-Integrationstests in Bamboo nicht nativ unterstützt, aber wo ein Wille ist, gibt es auch einen Weg. Dieser „Weg“ ist nicht gerade die eleganteste Art, Tests in Bamboo durchzuführen, aber er erreicht das Ziel:

Um eine Sammlung von Postman-Tests gegen eine Bereitstellung eines unserer Backend-Dienste ausführen zu können.

Das Team von Postman hat ein sehr nützliches npm-Paket namens entwickelt und veröffentlicht Newman. Newman ermöglicht es Benutzern, Postman-Testsammlungen über eine CLI-Schnittstelle aufzurufen. Da es in node.js entwickelt wurde, kann es problemlos während eines Build- oder Bereitstellungsplans in Bamboo aufgerufen werden. Jedoch Bamboo unterstützt Integrationstests für Bereitstellungen nicht direkt. Die Sammlung kann direkt nach der Bereitstellung mithilfe eines Skripts ausgeführt werden, um Newman aufzurufen, aber es gibt keine direkte Möglichkeit, die Ergebnisse zu analysieren und sie mit dieser Bereitstellung zu verknüpfen. Um diese Hürde zu überwinden, müssen wir uns die Hände ein wenig schmutzig machen.

Die von uns implementierte Lösung umfasste die Ausführung unserer Postman-Sammlung während des Bereitstellungsplans, das Hochladen der Testergebnisse in einen Amazon S3-Bucket, das Aufrufen eines völlig separaten Build-Plans über einen API-Aufruf und das anschließende Abrufen und Analysieren dieser Testergebnisse in diesen Buildplan. Es war sicherlich nicht das, was wir im Sinn hatten, als wir zum ersten Mal darüber nachgedacht haben, Postman in Bamboo zu integrieren, und es gibt einige Einschränkungen beim Design, aber es erfüllt den Zweck.

Obwohl es möglich ist, nach einer erfolgreichen Bereitstellung mithilfe von Bamboo-Triggern einen weiteren Build-Plan auszulösen, haben wir uns gegen diesen Ansatz entschieden. Wir wollten sicherstellen, dass bei jeder erfolgreichen Bereitstellung unsere Postman-Sammlungstests ausgeführt und korrekt analysiert werden. Dazu haben wir unserem zweiten Buildplan mitgeteilt, wo die Testergebnisse zu finden sind, die er analysieren soll. Wenn wir versucht hätten, Trigger für dieselbe Aufgabe zu verwenden, wären wir auf das Problem gestoßen, dass wir dem Build nicht sagen könnten, wo die Testergebnisse zu finden sind. Wir hätten einen statischen Ort angeben können, an den wir die neuesten Testergebnisse schreiben würden, aber bei diesem Ansatz gab es einige Randfallszenarien, die dazu geführt haben könnten, dass einige Testergebnisse nicht analysiert wurden. Allerdings ist die Verwendung von Triggern zum Aufrufen des Build-Plans anstelle eines API-Aufrufs eine absolut gültige Strategie, und ich bin mir sicher, dass es Lösungen für die oben genannten Probleme gibt.

Eine Postman-Sammlung einrichten, die nach der Bereitstellung ausgeführt wird

Bevor wir damit beginnen konnten, unsere Sammlung so einzurichten, dass sie nach der Bereitstellung unseres Dienstes ausgeführt werden konnte, mussten wir sicherstellen, dass unser Bereitstellungsplan Zugriff auf die Sammlung und die Umgebungen hatte, die wir verwenden wollten. Eine Möglichkeit, dies zu erreichen, besteht darin, die Sammlung und die Umgebungen in einem Quellcodeverwaltungssystem zu speichern. Wenn Sie dies tun, erstellen Sie zu Beginn der Bereitstellung eine Aufgabe, um die Sammlung und die Umgebungen aus dem Remote-Repository abzurufen. In unserem Fall haben wir beschlossen, die Dinge einfach zu halten und unsere Sammlungen zusammen mit dem Code zu speichern, mit dem unsere Sammlungstests interagieren. Dies bedeutete, dass wir bereits im Buildplan, dem unser Bereitstellungsplan vorausging, Zugriff auf unsere Sammlungstests hatten.

Im Buildplan haben wir das Repository unseres Dienstes abgerufen, unsere Komponententests durchgeführt und unsere Artefakte erstellt. Eines der Artefakte, die wir mit unserem Build erstellt haben, waren die Postman-Sammlungen und -Umgebungen, die wir nach der Bereitstellung testen wollten.

Im Einsatzplan haben wir eine Aufgabe hinzugefügt, um dieses Artefakt aus dem vorherigen Build herunterzuladen.

Mit dem Zugriff auf die Sammlung begannen wir mit der Konfiguration der Ausführung der Sammlung und der Tests. Um die Sammlung für kürzlich bereitgestellte Endpunkte auszuführen, haben wir am Ende der Bereitstellung eine zusätzliche Aufgabe erstellt. Die zusätzliche Aufgabe rief ein Skript auf, das Newman zur Ausführung der Postman-Tests verwendete. Wir haben beschlossen, dieses Skript in das Build-Artefakt aufzunehmen, das unsere Postman-Sammlung enthält, um den Zugriff darauf zu erleichtern.

Wie Sie Ihr Skript konfigurieren, liegt bei Ihnen, aber wenn Sie dem von uns verwendeten Ansatz folgen möchten, müssen Sie einige Codeabschnitte hinzufügen. Installieren Sie zuerst Newman und weisen Sie es an, Ihre Postman-Sammlung auszuführen.

Wenn Sie Newman ausführen, können Sie den Speicherort angeben, an dem das Ergebnis Ihrer Erfassungstests gespeichert werden soll. Im obigen Codeausschnitt verwenden wir die Variable $Folder.

Verwenden Sie dann die AWS-CLI, um die Testergebnisse hochzuladen. Um sicherzustellen, dass jede Testergebnisdatei eindeutig identifizierbar ist, haben wir uns dafür entschieden, die Variable bamboo_deploy_release an das Ende jedes Testergebnisdateinamens anzuhängen.

Rufen Sie von hier aus den Buildplan auf, der die Testergebnisse analysiert. Wir haben dieselbe bamboo_deploy_release Variable weitergegeben, um die richtigen Testergebnisse identifizieren und herunterladen zu können.

Analysieren und Melden der Ergebnisse von Erfassungstests

Nachdem all dies eingerichtet ist, erstellen Sie den Buildplan und konfigurieren Sie ihn so, dass die Ergebnisse der Erfassungstests analysiert werden. Wenn Sie mit Bamboo vertraut sind, ist dies ganz einfach zu erreichen. Zuerst müssen wir den Plan erstellen.

Dann müssen wir den Plan konfigurieren und ihm einige Aufgaben hinzufügen.

Wir haben eines der Repositorys überprüft, das ein Shell-Skript enthielt, das wir zum Herunterladen der Sammlungstestergebnisse von S3 erstellt hatten.

Schließlich haben wir JUnit verwendet, um die Testergebnisse zu analysieren.

Wenn Sie bei der Bereitstellung alles korrekt eingerichtet haben, sollte Ihre Postman-Sammlung ausgeführt werden und die Ergebnisse sollten im oben erstellten Buildplan gemeldet werden.

Eine Zusammenfassung der Ereignisse

Codeänderung beim Branch -> Bamboo-Build beginnt per Trigger -> Build wird ausgeführt, Postman-Sammlungsartefakte werden erstellt -> Die Bamboo-Bereitstellung beginnt per Trigger -> Die Bamboo-Bereitstellung greift auf Bamboo-Build zu -> Die Bamboo-Bereitstellung führt Ihr Postman-PowerShell-Skript aus -> Die Postman-Sammlung wird auf S3 hochgeladen -> Ein separater Bamboo-Build wird durch einen API-Aufruf ausgelöst -> Der separate Bamboo-Build führt das Download-Skript aus und analysiert die Sammeltestergebnisse

Probleme und Dinge, die wir besser hätten machen können

Aufgrund der Art der Implementierung gab es ein kleines Missverhältnis zwischen der Bereitstellung des Dienstes und den Postman-Sammlungen, die dem entgegenstanden. Da Bamboo Integrationstests nicht von Haus aus unterstützt, haben wir die Testergebnisse in einem separaten Build-Plan analysiert. Dies war problematisch, da dadurch eine Kluft zwischen der Bereitstellung und den Tests entstand. Sollten einige der Postman-Tests fehlschlagen, würde der Einsatz dennoch als erfolgreich gewertet werden — soweit es das Unternehmen betrifft, hat es alle seine Aufgaben erfolgreich ausgeführt. Dies kann die Suche nach der Ursache von Testfehlern schwieriger machen, als es sein sollte.

Trotz der Probleme erwies sich die von uns implementierte Lösung immer noch als vorteilhaft. Ein Paradebeispiel dafür war die Erhöhung des Bekanntheitsgrads für den Servicestatus. Wenn unsere Postman-Sammlungstests aus irgendeinem Grund fehlschlagen, können wir Benachrichtigungen konfigurieren, die das zugewiesene Entwicklungsteam benachrichtigen. Wenn diese Situation eintritt, helfen die Testergebnisse der Postman Collection Entwicklern dabei, die vorhandenen Probleme zu diagnostizieren und zu verstehen. Durch die Anzeige der Ergebnisse der Sammeltests in Bamboo kann ein Entwickler leicht erkennen, welche Tests fehlgeschlagen sind und welche bestanden haben. Ohne Integrationstests wie diese wird es immer schwieriger, Probleme und Bugs zu identifizieren und zu beheben.