Automatisierte API-Tests in Azure Pipelines ausführen: Schritt-für-Schritt-Anleitung

Ihre API funktioniert auf Ihrem Laptop. Sie besteht jede Prüfung in Ihrem lokalen Testclient. Dann führt ein Teamkollege einen Branch zusammen, das Deployment wird durchgeführt, und ein Endpunkt, der zuvor 200 zurückgab, liefert in der Produktion 500. Niemand hat es bemerkt, weil niemand die Tests auf diesem Branch ausgeführt hat. Sie wurden einmal manuell auf einer Maschine ausgeführt.

Diese Lücke zwischen „Tests existieren“ und „Tests werden bei jeder Änderung ausgeführt“ schließt eine CI-Pipeline. Wenn Ihr Code bereits in Azure Repos oder GitHub liegt und Ihr Team auf Azure DevOps aufbaut, ist Azure Pipelines der natürliche Ort, um dieses Sicherheitsnetz zu platzieren. Der schwierige Teil ist selten das YAML. Es geht darum, Ihre API-Testsuite in eine Form zu bringen, die die Pipeline headless, mit der richtigen Umgebung, gegen einen frisch deployten Build ausführen kann und dann den Build lautstark fehlschlagen lässt, wenn etwas kaputtgeht.

TL;DR

• Azure Pipelines führt Ihre API-Tests bei jedem Commit oder PR automatisch aus, sodass Regressionen erkannt werden, bevor sie in Produktion gehen.
• Erstellen Sie Ihre Testszenarien visuell in Apidog und führen Sie sie dann in CI mit der Apidog CLI (apidog-cli) aus, anstatt Testskripte manuell zu schreiben und zu pflegen.
• Die Pipeline benötigt vier Dinge: Node.js auf dem Agent installiert, die CLI installiert, Ihr Testszenario über einen Link oder eine exportierte Datei erreichbar, und einen als Geheimnis gespeicherten Zugriffstoken.
• Ein Exit-Code ungleich Null von der CLI lässt den Build automatisch fehlschlagen. Das ist es, was Ihnen ein echtes Gate verschafft.
• Veröffentlichen Sie den HTML- oder JUnit-Bericht als Pipeline-Artefakt (oder über PublishTestResults), damit jeder den Pass/Fail-Status lesen kann, ohne Logs öffnen zu müssen.

Was „automatisiertes API-Testen in Azure Pipelines“ wirklich bedeutet

Azure Pipelines ist der CI/CD-Dienst innerhalb von Azure DevOps. Sie beschreiben einen Build in einer YAML-Datei (azure-pipelines.yml), die in Ihrem Repository liegt, und Azure führt diese Datei auf einem gehosteten oder selbst gehosteten Agent aus, jedes Mal wenn ein Trigger ausgelöst wird; ein Push, ein Pull Request, ein Zeitplan oder ein manueller Lauf.

Für API-Tests ist die Aufgabe im Wesentlichen unkompliziert:

1. Einen Agent starten (eine saubere VM).
2. Alles installieren, was Ihr Test-Runner benötigt.
3. Die API-Tests gegen eine Zielumgebung ausführen.
4. Die Ergebnisse melden und den Build-Status entsprechend festlegen.

Das Detail, das die Leute stolpern lässt, ist Schritt 3. Ein lokaler API-Client ist interaktiv; Sie klicken auf „Senden“, Sie überprüfen die Antwort visuell, Sie sehen einen grünen Haken. Eine Pipeline hat niemanden zum Klicken und niemanden zum visuellen Überprüfen. Sie benötigen eine Möglichkeit, dieselben Assertionen ohne menschliche Interaktion und ohne GUI auszuführen. Das ist der ganze Grund, warum ein Kommandozeilen-Runner existiert.

Wenn Sie eine umfassendere Einführung in die hier verwendeten CI-Konzepte wünschen, lohnt es sich, den Unterschied zwischen Continuous Integration, Continuous Delivery und Continuous Deployment kurz zu lesen, bevor Sie Ihre erste Pipeline einrichten.

Warum Tests in Apidog entwerfen und mit der CLI ausführen

Sie könnten API-Tests in rohem Code schreiben. Wählen Sie eine Sprache, integrieren Sie eine HTTP-Bibliothek und ein Assertion-Framework, erstellen Sie Anforderungsbodies manuell, parsen Sie Antworten, verwalten Sie Auth-Token und halten Sie all dies mit einer API synchron, die sich jeden Sprint ändert. Teams tun dies. Sie verbringen aber auch einen unverhältnismäßig großen Teil ihrer Zeit mit der Wartung.

Apidog geht einen anderen Weg. Sie erstellen Testszenarien visuell: Ketten Sie Anfragen aneinander, übergeben Sie Daten von einer Antwort an die nächste Anfrage, fügen Sie Assertionen für Statuscodes, Header und JSON-Felder hinzu und steuern Sie dasselbe Szenario mit mehreren Datenzeilen. Da Apidog bereits Ihre API-Definitionen enthält, bleiben die Tests nah an der Spezifikation. Wenn sich das Schema ändert, sehen Sie die Abweichung, anstatt sie erst in der Produktion zu entdecken.

Das Element, das diese visuelle Arbeit mit CI verbindet, ist die Apidog CLI, ein auf npm veröffentlichter Kommandozeilen-Runner. Sie führt ein gespeichertes Testszenario headless aus und beendet sich mit einem Statuscode, der das Ergebnis widerspiegelt: 0, wenn alles bestanden wurde, und ungleich Null, wenn eine Assertion fehlgeschlagen ist. Dieser Exit-Code ist der Vertrag, den jedes CI-System versteht. Azure Pipelines liest ihn und entscheidet, ob der Build grün oder rot ist. Sie entwerfen einmal in der GUI, und dasselbe Szenario läuft unverändert in der Pipeline.

Dies ist dasselbe Modell, das für GitHub Actions, GitLab CI und Jenkins funktioniert. Azure Pipelines ist lediglich ein weiterer Host für denselben CLI-Befehl, was bedeutet, dass sich das Wissen überträgt, falls Ihr Team jemals die Plattform wechselt.

Voraussetzungen

• Ein Apidog-Projekt mit mindestens einem Testszenario. Öffnen Sie den Bereich „Test Scenarios“, erstellen Sie ein Szenario, fügen Sie einige Anfragen hinzu und verknüpfen Sie Assertionen. Führen Sie es einmal lokal aus und bestätigen Sie, dass es bestanden wird. Wenn es auf Ihrem Rechner instabil ist, wird es auch in CI instabil sein.
• Ein Apidog-Zugriffstoken. Die CLI authentifiziert sich mit einem persönlichen Zugriffstoken aus Ihren Apidog-Kontoeinstellungen. Behandeln Sie es wie ein Passwort; Sie speichern es als Pipeline-Geheimnis, niemals im YAML.
• Ein Azure DevOps-Projekt mit einem Repository. Ihre azure-pipelines.yml wird im Stammverzeichnis des Repositorys liegen.
• Vertrautheit mit Node.js (gering). Die CLI läuft auf Node, daher muss Node auf dem Agent installiert sein. Azures gehostete Agents haben es bereits; Sie müssen nur eine Version auswählen.
• Eine erreichbare Zielumgebung. Ihre Tests müssen eine laufende API ansprechen; eine Staging-URL, ein Vorab-Deployment oder einen Dienst, den die Pipeline selbst startet. Entscheiden Sie dies, bevor Sie den Trigger schreiben.

Ein kurzer Hinweis dazu, welche Zielumgebung getestet werden soll. Die Ausführung der Suite gegen die Produktion bei jedem Commit ist riskant und oft unmöglich (Sie möchten keine Testdaten in der Produktion). Die meisten Teams richten CI-Tests auf eine Staging-Umgebung oder ein pro-Branch-Vorschau-Deployment aus. Apidog-Umgebungen machen dies sauber: Halten Sie eine Staging-Umgebung mit ihrer eigenen Basis-URL und Variablen bereit und teilen Sie der CLI zur Laufzeit mit, welche davon zu verwenden ist.

Schritt 1: Ihr Testszenario in eine ausführbare Form bringen

Die CLI muss wissen, welches Szenario ausgeführt werden soll. Apidog bietet Ihnen zwei Möglichkeiten, dies zu übermitteln.

Option A, Ausführung über einen freigegebenen Online-Link. Öffnen Sie in Apidog Ihr Testszenario, wählen Sie die Ausführung über die CLI, und Apidog generiert einen Befehl, der über das Netzwerk auf das Szenario verweist. Dies ist die wartungsärmere Option: Die Pipeline führt immer die aktuelle Version des Szenarios aus, und Sie müssen keine Testdateien ins Repository committen. Der Kompromiss ist, dass die Pipeline davon abhängt, dass dieser Link zur Laufzeit erreichbar ist.

Option B, das Szenario in eine Datei exportieren und committen. Exportieren Sie das Szenario (und seine Umgebung) in eine lokale Datei, committen Sie es zusammen mit Ihrem Code und lassen Sie die CLI auf den Dateipfad zeigen. Dies bindet den Test an einen bestimmten Commit, was Sie wünschen, wenn Ihnen Reproduzierbarkeit wichtig ist; die ausgeführten Tests sind genau die Tests in diesem Commit. Der Kompromiss ist, dass Sie neu exportieren müssen, wenn sich das Szenario ändert.

Für die meisten Teams, die beginnen, ist Option A schneller einzurichten. Bei regulierten oder audit-intensiven Arbeiten gewinnt die Reproduzierbarkeit von Option B. Sie können auch mischen: Link-basiert für sich schnell ändernde Feature-Branches, dateibasiert für Release-Branches.

In jedem Fall notieren Sie den genauen Ausführungsbefehl, den Apidog Ihnen gibt. Er wird ungefähr so aussehen:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t <access-token> \
 -e <environment-id>

Die Flags, die Sie am häufigsten verwenden werden:

• die Szenario-Referenz (ein Online-Link oder ein lokaler Dateipfad),
• -t / Zugriffstoken zur Authentifizierung,
• -e für die Umgebung, gegen die ausgeführt werden soll,
• eine Reporter-Option zur Steuerung des Ausgabeformats (CLI-Text, HTML oder eine maschinenlesbare Zusammenfassung),
• eine Iterationsanzahl, wenn Sie möchten, dass das Szenario über einen Datensatz läuft.

Bestätigen Sie die genauen Flag-Namen anhand des Ausführungsbefehls, den Apidog für Ihr Szenario generiert; der Runner gibt die Verwendung mit apidog run --help aus. Raten Sie nicht bei den Flags; kopieren Sie die, die Apidog Ihnen gibt, und parametrisieren Sie die Geheimnisse.

Schritt 2: Überprüfen Sie zuerst, ob die CLI lokal funktioniert

Debuggen Sie ein neues Tool niemals innerhalb von CI. Pipeline-Feedback-Loops sind langsam und die Logs sind lauter als Ihr Terminal. Führen Sie zuerst einen erfolgreichen Durchlauf auf Ihrem eigenen Rechner aus.

Installieren Sie die CLI:

npm install -g apidog-cli

Führen Sie dann Ihr Szenario aus:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t "$APIDOG_ACCESS_TOKEN" \
 -e "<staging-environment-id>"

Sie überprüfen drei Dinge:

1. Der Befehl wird beendet und gibt eine Zusammenfassung des Erfolgs/Fehlers aus.
2. Der Exit-Code stimmt mit dem Ergebnis überein. Führen Sie direkt danach echo $? aus; er sollte bei Erfolg 0 und bei Fehler ungleich Null sein.
3. Die Umgebung wurde korrekt aufgelöst; die Anfragen treffen Ihre Staging-URL, nicht eine verbleibende lokale.

Diese Exit-Code-Überprüfung ist wichtiger, als es scheint. Wenn die CLI 0 zurückgibt, selbst wenn eine Assertion fehlschlägt, wird Ihre Pipeline bei defektem Code als erfolgreich angezeigt, was schlimmer ist, als überhaupt keine Tests zu haben. Erzwingen Sie einmal einen Fehler (brechen Sie absichtlich eine Assertion) und bestätigen Sie, dass Sie einen Code ungleich Null erhalten. Setzen Sie dann die Assertion wieder zurück.

Schritt 3: Erstellen Sie das Azure Pipelines YAML

Fügen Sie eine Datei namens azure-pipelines.yml zum Stammverzeichnis Ihres Repositorys hinzu. Dies ist ein vollständiger, funktionierender Ausgangspunkt für einen gehosteten Ubuntu-Agent:

trigger:
 branches:
 include:
 - main
 - develop

pr:
 branches:
 include:
 - main

pool:
 vmImage: ubuntu-latest

variables:
 NODE_VERSION: '20.x'

steps:
 - task: NodeTool@0
 inputs:
 versionSpec: $(NODE_VERSION)
 displayName: 'Install Node.js'

 - script: npm install -g apidog-cli
 displayName: 'Install Apidog CLI'

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'

Gehen wir es durch:

• trigger führt die Pipeline bei jedem Push auf main und develop aus. Passen Sie dies an Ihre Branch-Namen an.
• pr führt sie bei Pull-Requests aus, die auf main abzielen. Dies ist das Gate, das verhindert, dass ein defekter Branch zusammengeführt wird.
• pool / vmImage wählt einen von Microsoft gehosteten Ubuntu-Agenten aus. Keine Infrastruktur zu verwalten.
• NodeTool@0 installiert eine bestimmte Node-Version, sodass Ihre Läufe reproduzierbar sind.
• Der Installationsschritt holt die CLI bei jedem Lauf neu. Für schnellere Builds können Sie node_modules cachen oder eine Version festlegen, aber beginnen Sie einfach.
• Der Ausführungsschritt ist der entscheidende. Wenn eine Assertion fehlschlägt, beendet apidog run mit einem Code ungleich Null, der Skript-Task schlägt fehl und der gesamte Build wird rot.

Die $(...)-Referenzen sind Pipeline-Variablen. SCENARIO_ID, STAGING_ENV_ID und insbesondere APIDOG_ACCESS_TOKEN stammen aus dem nächsten Schritt und sind hier nicht fest kodiert.

Schritt 4: Geheimnisse richtig speichern

Ihr Zugriffstoken darf niemals im Klartext im YAML stehen. Jeder, der Lesezugriff auf das Repository hat, würde es sehen, und es gewährt Zugriff auf Ihr Apidog-Projekt.

Verwenden Sie eine geheime Pipeline-Variable:

1. Öffnen Sie in Azure DevOps Ihre Pipeline und wählen Sie Bearbeiten, dann Variablen (oder Bibliothek für eine freigegebene Variablengruppe).
2. Fügen Sie APIDOG_ACCESS_TOKEN hinzu und fügen Sie den Token ein.
3. Schalten Sie das Schlosssymbol um, um es als geheim zu markieren. Azure verschlüsselt es und maskiert es in den Protokollen.

Geheime Variablen werden nicht automatisch in die Shell-Umgebung injiziert; Sie ordnen sie explizit im Schritt zu. Aktualisieren Sie den Ausführungsschritt, um das Geheimnis über env zu übergeben:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

SCENARIO_ID und STAGING_ENV_ID müssen nicht geheim sein; behandeln Sie sie als einfache Variablen zur besseren Lesbarkeit oder verschieben Sie sie in eine Variablengruppe, die Sie pipelineübergreifend wiederverwenden. Für Teams, die viele Geheimnisse verwalten, sichern Sie die Variablengruppe mit Azure Key Vault, damit die Rotation an einem zentralen Ort erfolgt.

Schritt 5: Einen lesbaren Testbericht veröffentlichen

Ein roter Build sagt Ihnen, dass etwas kaputt ist. Er sagt Ihnen nicht, was. Die Lösung besteht darin, dass die CLI einen Bericht ausgibt und Azure diesen sichtbar macht.

Die Apidog CLI kann ihre Ergebnisse in eine Berichtsdatei schreiben. Verweisen Sie sie auf ein Ausgabeformat (HTML für Menschen, ein JUnit-ähnliches XML, wenn Sie Azures native Testansicht wünschen) und ein Ausgabeverzeichnis, und veröffentlichen Sie dann dieses Verzeichnis.

Für ein menschenlesbares Artefakt:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID) \
 -r html \
 --out-dir $(Build.ArtifactStagingDirectory)/api-report
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

 - task: PublishBuildArtifacts@1
 condition: always()
 inputs:
 pathToPublish: $(Build.ArtifactStagingDirectory)/api-report
 artifactName: api-test-report
 displayName: 'Publish API test report'

Zwei Dinge sind zu beachten. Erstens bewirkt condition: always(), dass der Veröffentlichungsschritt auch dann ausgeführt wird, wenn der Testschritt fehlschlägt; das ist der ganze Sinn, da Sie den Bericht am meisten wünschen, wenn etwas kaputtgegangen ist. Zweitens überprüfen Sie das genaue Reporter-Flag (-r, --reporter oder ähnlich) und die Ausgabeoption anhand von apidog run --help für Ihre CLI-Version und passen Sie dann das Beispiel entsprechend an.

Wenn Sie Ergebnisse lieber im integrierten Test-Tab von Azure mit Trenddiagrammen sehen möchten, lassen Sie die CLI JUnit XML ausgeben und fügen Sie einen PublishTestResults@2-Task hinzu, der auf das XML verweist. Das gibt Ihnen eine Assertions-Historie über mehrere Builds hinweg, nicht nur eine einmalige Datei.

Schritt 6: Das Gate real machen

Das Einrichten der Pipeline ist nicht dasselbe wie ihre Durchsetzung. Standardmäßig hindert ein fehlerhafter Build niemanden am Zusammenführen, es sei denn, Sie weisen Azure DevOps an, dies zu erzwingen.

Richten Sie eine Branch-Richtlinie für main ein:

1. Gehen Sie zu Repos, dann Branches, suchen Sie main und öffnen Sie die Branch-Richtlinien.
2. Fügen Sie Build-Validierung hinzu und wählen Sie Ihre Pipeline aus.
3. Setzen Sie es auf erforderlich.

Nun kann ein Pull Request nicht in main zusammengeführt werden, bevor die API-Testpipeline bestanden wurde. Das ist der Unterschied zwischen Tests, die ausgeführt werden, und Tests, die schützen. Bis Sie dies einschalten, haben Sie ein Dashboard; danach haben Sie ein Gate.

Ein realistisches datengesteuertes Beispiel

Einzelszenarien fangen offensichtliche Fehler ab. Echte APIs müssen denselben Endpunkt mit vielen Eingaben testen; gültige Payloads, Edge Cases, die fehlerhafte Anfrage, die 400 statt 500 zurückgeben sollte.

Apidog unterstützt datengesteuertes Testen: Hängen Sie einen CSV- oder JSON-Datensatz an ein Szenario an, und es wird einmal pro Zeile ausgeführt, wobei die Werte der Zeile in Anfragen und Assertionen eingesetzt werden. Ein Anmeldeszenario könnte beispielsweise Zeilen für einen gültigen Benutzer, ein falsches Passwort, ein gesperrtes Konto und einen leeren Body ausführen, jeweils mit seinem eigenen erwarteten Statuscode.

In der Pipeline ändert sich nichts an der Form des Befehls; Sie rufen apidog run weiterhin gegen dasselbe Szenario auf. Der Datensatz reist mit dem Szenario, sodass ein einziger CLI-Aufruf jede Zeile abdeckt. Wenn Sie einen neuen Edge Case in Apidog hinzufügen, wird dieser vom nächsten Pipeline-Lauf ohne YAML-Bearbeitung übernommen. Das ist der Vorteil, die Testlogik im Tool statt in der Pipeline zu halten: Die Pipeline bleibt langweilig, während Ihre Abdeckung wächst.

Häufige Probleme und deren Behebung

• Der Build ist erfolgreich, obwohl ein Endpunkt defekt ist. Fast immer ein Exit-Code-Problem. Bestätigen Sie, dass die CLI bei Fehlern einen Wert ungleich Null zurückgibt (Schritt 2), und stellen Sie sicher, dass Sie ihn nicht verschlucken; ein nachgestelltes || true oder ein Multi-Befehls-Skript, das mit einem anderen Befehl endet, wird den Fehler maskieren. Halten Sie den apidog run-Aufruf als letzten sinnvollen Befehl in seinem Skriptblock.
• apidog: Befehl nicht gefunden. Der Installationsschritt wurde nicht ausgeführt, wurde nach dem Testschritt ausgeführt oder in einen Pfad installiert, den die Shell des Agenten nicht sehen kann. Bestätigen Sie, dass npm install -g apidog-cli vor dem Ausführungsschritt erscheint. Auf einigen selbst gehosteten Agenten befindet sich das globale npm-Bin nicht im PATH; installieren Sie es lokal und rufen Sie es stattdessen über npx apidog run ... auf.
• Die Authentifizierung schlägt in CI fehl, funktioniert aber lokal. Das Geheimnis erreicht den Schritt nicht. Geheime Variablen müssen über env: (Schritt 4) gemappt werden; sie werden nicht automatisch injiziert. Überprüfen Sie auch, ob der Token nicht mit einem abschließenden Zeilenumbruch oder einem Anführungszeichen eingefügt wurde.
• Tests treffen die falsche Umgebung. Der -e-Wert zeigt auf die falsche Apidog-Umgebung, oder die Basis-URL der Umgebung verweist immer noch auf localhost. Halten Sie eine dedizierte Staging-Umgebung bereit, deren Variablen auf erreichbare, CI-sichere URLs verweisen, und übergeben Sie deren ID explizit.
• Instabiler Pass/Fail über mehrere Läufe hinweg. Meistens geteilter, veränderlicher Zustand; ein Test, der einen Datensatz erstellt, und ein späterer Lauf, der damit kollidiert. Machen Sie Szenarien in sich abgeschlossen: Erstellen Sie, was Sie brauchen, bestätigen Sie, räumen Sie dann auf, oder verwenden Sie eindeutige Bezeichner pro Lauf, damit Wiederholungen nicht über die Daten von gestern stolpern. Wenn Sie von einem anderen Tool migrieren, decken die Muster in wie man API-Tests in CI ohne Newman ausführt dieselben Isolationsfallen ab.

Jenseits der Grundlagen

Sobald die Kern-Pipeline solide ist, zahlen sich einige Erweiterungen aus:

• Planen Sie einen nächtlichen Lauf. Fügen Sie einen schedules-Trigger hinzu, um die gesamte Suite um 2 Uhr morgens gegen Staging auszuführen, damit Sie Abweichungen durch Datenänderungen oder API-Änderungen von Drittanbietern auch an Tagen erkennen, an denen niemand Code pusht.
• Teilen Sie schnelle und langsame Suiten auf. Führen Sie ein schnelles Smoke-Szenario bei jedem PR für schnelles Feedback aus und die vollständige Regression-Suite bei Merges nach main. Zwei Pipeline-Definitionen, dieselbe CLI.
• Testen Sie mehrere Umgebungen in einer Matrix. Verwenden Sie eine Pipeline-Matrix, um dasselbe Szenario parallel gegen Staging und eine Pre-Prod-Umgebung auszuführen, jede mit ihrer eigenen Umgebungs-ID.
• Sichern Sie das Deployment, nicht nur das Merge. Platzieren Sie die API-Testphase vor Ihrer Deploy-Phase in einer mehrstufigen Pipeline, sodass ein fehlgeschlagener Test die Freigabe stoppt, nicht nur das Zusammenführen.

Jede dieser Erweiterungen ist eine kleine Ergänzung zur selben Grundlage: eine CLI, die sauber beendet wird, und eine Pipeline, die den Exit-Code respektiert.

Häufig gestellte Fragen

• Muss ich Code schreiben, um API-Tests in Azure Pipelines auszuführen? Nein. Sie erstellen die Testszenarien visuell in Apidog, und die Pipeline führt sie mit einem einzigen CLI-Befehl aus. Der einzige „Code“ ist die azure-pipelines.yml selbst, die Konfiguration und keine Testlogik ist. Wenn Sie vollständig skriptbasierte Tests bevorzugen, können Sie das immer noch tun, aber der Sinn dieses Workflows ist es, dies zu umgehen.
• Kann ich meine bestehenden Postman-Sammlungen stattdessen in Azure Pipelines ausführen? Ja, typischerweise mit Newman oder einem ähnlichen Runner. Wenn Sie die Optionen abwägen, importiert Apidog Postman-Sammlungen direkt, sodass Sie bestehende Tests einbringen und über dieselbe CLI ausführen können, ohne eine separate Toolchain pflegen zu müssen. Sehen Sie unter wie man API-Tests in CI ohne Newman ausführt für den Vergleich.
• Wohin sollen die Tests zeigen; Staging oder Produktion? Fast immer auf Staging oder eine pro-Branch-Vorschau-Umgebung. Das Ausführen von schreibintensiven Tests gegen die Produktion verschmutzt echte Daten und kann reale Nebenwirkungen auslösen. Halten Sie eine dedizierte Apidog-Umgebung für CI mit sicheren Basis-URLs bereit und übergeben Sie deren ID mit -e an die CLI.
• Woher weiß die Pipeline, dass ein Test fehlgeschlagen ist? Durch den Exit-Code. apidog run gibt 0 zurück, wenn jede Assertion bestanden wird, und einen Wert ungleich Null, wenn eine fehlschlägt. Azure Pipelines lässt den Skript-Task bei einem Exit ungleich Null fehlschlagen, was den Build fehlschlagen lässt. Überprüfen Sie dies einmal lokal mit echo $?, damit Sie dem Gate vertrauen können.
• Funktioniert dies auch mit Azure DevOps Classic (UI)-Pipelines, nicht nur mit YAML? Ja. Die gleichen Schritte gelten; fügen Sie einen „Use Node“-Task, einen Kommandozeilen-Task, der npm install -g apidog-cli ausführt, und einen weiteren Kommandozeilen-Task hinzu, der apidog run ... ausführt. YAML wird empfohlen, da es in Ihrem Repository lebt und versionskontrolliert ist, aber der Runner kümmert sich nicht darum, wie die Schritte definiert sind.
• Kann ich stattdessen einen selbst gehosteten Agenten anstelle eines von Microsoft gehosteten verwenden? Ja. Selbst gehostete Agenten funktionieren auf die gleiche Weise; stellen Sie einfach sicher, dass Node.js installiert ist und das globale npm-Bin im PATH des Agenten liegt, oder rufen Sie die CLI über npx auf. Selbst gehostete Agenten sind nützlich, wenn Ihre Staging-API nur innerhalb eines privaten Netzwerks erreichbar ist.

Zusammenfassung

Ein grüner CI-Build sollte bedeuten, dass Ihre API tatsächlich funktioniert, nicht nur, dass der Code kompiliert wurde. Dies in Azure Pipelines zu erreichen, läuft auf vier Schritte hinaus: Entwerfen Sie echte Testszenarien in Apidog, führen Sie sie headless mit der Apidog CLI aus, lassen Sie den Exit-Code den Build-Status steuern und verlangen Sie, dass der Build bestanden wird, bevor etwas zusammengeführt wird. Sobald dieser Kreislauf läuft, erhält jeder Push dieselbe sorgfältige Prüfung, die Ihr sorgfältigster Teamkollege ihm geben würde, automatisch, jedes Mal.

Der Grund, warum dies wartbar bleibt, ist die Trennung. Die Testlogik lebt in Apidog, wo sie nah an Ihrer API-Spezifikation ist und einfach erweitert werden kann. Die Pipeline bleibt ein dünner Wrapper; installieren, ausführen, berichten. Wenn Ihre API wächst, fügen Sie Szenarien und Datenzeilen im Tool hinzu, und die Pipeline erledigt weiterhin ihre eine Aufgabe ohne Bearbeitungen.

Bereit zum Einrichten? Laden Sie Apidog herunter, erstellen Sie ein Testszenario, schnappen Sie sich den CLI-Ausführungsbefehl und fügen Sie ihn in Ihre azure-pipelines.yml ein. Ihre nächste Regression wird von einer Maschine abgefangen, anstatt von einem Kunden entdeckt zu werden.