Automatisera dina API-tester i kontinuerlig integration

Ett scenario som byggts i gränssnittet körs som det är i din pipeline. Den här guiden handlar om att skala upp.

Förutsättningar

• En plan Pro eller Enterprise.
• En organisationstoken (rstk_…) att lägga i din CI:s hemlighetsvalv. (Möjligheten att skapa den token själv från kontrollpanelen kommer snart.)

Principen

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

Slutkod 0 = lyckat, 1 = scenariot misslyckades, 2 = anropsfel, 3 = nekad rättighet.

En virtuell skärm behövs

Restorm är en skrivbordsapplikation: även utan fönster behöver den en displayserver. På en Linux-runner sätter du xvfb-run -a framför.

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

Hemligheterna

Skriv aldrig in en hemlighet i projektet. Deklarera dina känsliga variabler med hemlighetskällan miljövariabel; din CI:s valv injicerar dem, Restorm läser dem. Se Hemligheter.

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

Parametrisera per miljö

Två kompletterande tillvägagångssätt:

1. En scenarioparameter av typen environment: --param Env=staging. Samma scenario körs mot vilket mål som helst.
2. Enkla parametrar: --param baseUrl=…, --param tenant=….

Konverteringen följer parameterns deklarerade typ, och en omöjlig konvertering gör att starten misslyckas omedelbart i stället för att köra med ett felaktigt värde. Se Variabler och data.

Publicera loggen

--out run.log skriver loggen efter hand. Publicera den som en artefakt, även när jobbet misslyckas — det är just då den behövs.

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

Skriv scenarier som är läsbara i CI

Några vanor som gör hela skillnaden när ett rött jobb dyker upp klockan tre på natten:

• Tydliga meddelanden i assertions. Fältet message i åtgärden Assert är det som hamnar i loggen: skriv där vad som förväntades.
• Logga vid de viktiga stegen. Utan --all-logs skickas bara posterna från åtgärden Log: det är din berättande tråd.
• Schemavalidering hellre än assertion fält för fält. Koppla utgången errors från Schema validate till en Log: du får den exakta listan över överträdelser.
• Throw på de kritiska else-utgångarna, så att slutkoden speglar misslyckandet.
• Retry runt instabila nätverksanrop, hellre än att acceptera test som fladdrar. Se Kontrollflöde.

Städa upp

Kedja upprensningen på huvudscenariots port done: done väntar tills hela delgrafen är klar. Se Portar och kopplingar.

Fallgropar att känna till

Fallgrop	Lösning
Jobbet väntar på inmatning	Skicka in alla parametrar med --param; i headless-läge går ingenting att fråga efter
En Toast-åtgärd visas inte	Det är normalt: den har ingen effekt i headless-läge. Använd Log
MCP-servern dyker inte upp	Det är avsiktligt: utan en riktig skärm startar den aldrig
Slutkod 3	Token eller planen — meddelandet anger vilket av de fyra fallen det är
Projektfilen har flyttat sig	--open accepterar en sökväg relativ till förvaret: håll den relativ

Fullständiga exempel

Pipelines för GitHub Actions och GitLab CI finns i Headless-körning och CI.