API-Tests in Continuous Integration automatisieren

Ein in der Oberfläche gebautes Szenario läuft unverändert in Ihrer Pipeline. Dieser Leitfaden behandelt die Skalierung.

Voraussetzungen

• Ein Pro- oder Enterprise-Tarif.
• Ein Organisations-Token (rstk_…), das Sie im Secrets-Tresor Ihrer CI ablegen. (Die Self-Service-Erstellung dieses Tokens über das Dashboard kommt in Kürze.)

Das Prinzip

RESTORM_TOKEN=$RESTORM_TOKEN restorm \
  --open ./api.restorm \
  --run "Tests de fumée" \
  --headless \
  --all-logs \
  --out run.log \
  --param baseUrl=$BASE_URL

Exit-Code 0 = Erfolg, 1 = Szenario fehlgeschlagen, 2 = Aufruffehler, 3 = Zugriff verweigert.

Eine virtuelle Anzeige ist erforderlich

Restorm ist eine Desktop-Anwendung: Selbst ohne Fenster benötigt sie einen Display-Server. Stellen Sie auf einem Linux-Runner xvfb-run -a voran.

xvfb-run -a restorm --open ./api.restorm --run "Tests de fumée" --headless

Die Secrets

Schreiben Sie niemals ein Secret in das Projekt. Deklarieren Sie Ihre sensiblen Variablen mit der Secret-Quelle Umgebungsvariable; der Tresor Ihrer CI injiziert sie, Restorm liest sie. Siehe Secrets.

env:
  API_TOKEN: ${{ secrets.API_TOKEN }}

Nach Umgebung parametrisieren

Zwei sich ergänzende Ansätze:

1. Ein Szenarioparameter vom Typ environment: --param Env=staging. Dasselbe Szenario läuft gegen ein beliebiges Ziel.
2. Einfache Parameter: --param baseUrl=…, --param tenant=….

Die Umwandlung folgt dem deklarierten Typ des Parameters, und eine unmögliche Umwandlung lässt den Start sofort fehlschlagen, statt mit einem falschen Wert auszuführen. Siehe Variablen und Daten.

Das Protokoll veröffentlichen

--out run.log schreibt das Protokoll laufend mit. Veröffentlichen Sie es als Artefakt, auch wenn der Job fehlschlägt – gerade dann ist es nützlich.

- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: journal-restorm
    path: run.log

Lesbare Szenarien für CI schreiben

Ein paar Gewohnheiten, die alles verändern, wenn um 3 Uhr morgens ein roter Job auftaucht:

• Explizite Assertion-Meldungen. Das Feld message der Aktion Assertion ist das, was im Protokoll erscheint: schreiben Sie hinein, was erwartet wurde.
• Protokollierung an Schlüsselstellen. Ohne --all-logs werden nur die Einträge der Aktion Log ausgegeben: Das ist Ihr roter Faden.
• Schemavalidierung statt Feld-für-Feld-Assertion. Verbinden Sie den Ausgang errors von Schema validieren mit einem Log: Sie erhalten die präzise Liste der Verstöße.
• Throw bei kritischen else-Ausgängen, damit der Exit-Code den Fehlschlag widerspiegelt.
• Retry um instabile Netzwerkaufrufe herum, statt intermittierende Tests hinzunehmen. Siehe Steuerung.

Aufräumen

Hängen Sie das Aufräumen an den Port done des Hauptszenarios: done wartet, bis der gesamte Teilgraph abgeschlossen ist. Siehe Ports und Verbindungen.

Bekannte Fallstricke

Fallstrick	Lösung
Der Job wartet auf eine Eingabe	Liefern Sie alle Parameter mit --param; im Headless-Modus kann nichts abgefragt werden
Eine Toast-Aktion wird nicht angezeigt	Das ist normal: Sie ist im Headless-Modus wirkungslos. Verwenden Sie Log
Der MCP-Server erscheint nicht	Das ist beabsichtigt: Ohne echte Anzeige startet er nie
Exit-Code 3	Das Token oder der Tarif – die Meldung präzisiert, welcher der vier Fälle vorliegt
Die Projektdatei hat sich verschoben	--open akzeptiert einen relativ zum Repository angegebenen Pfad: Halten Sie ihn relativ

Vollständige Beispiele

Die GitHub-Actions- und GitLab-CI-Pipelines finden Sie unter Headless-Ausführung und CI.