Automatisere API-testene i kontinuerlig integrasjon

Et scenario du har bygget i grensesnittet, kjører som det er i pipelinen din. Denne veiledningen dekker overgangen til drift i stor skala.

Forutsetninger

• En Pro- eller Enterprise-plan.
• Et organisasjonstoken (rstk_…) som legges i hemmelighetshvelvet til CI-en din. (Selvbetjent opprettelse av dette tokenet fra dashbordet kommer snart.)

Prinsippet

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

Exitkode 0 = suksess, 1 = scenarioet feilet, 2 = feil i selve kallet, 3 = rettighet nektet.

Du trenger en virtuell skjerm

Restorm er en skrivebordsapplikasjon: selv uten vindu trenger den en skjermtjener. På en Linux-runner setter du xvfb-run -a foran.

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

Hemmelighetene

Skriv aldri en hemmelighet inn i prosjektet. Deklarer de sensitive variablene dine med hemmelighetskilden miljøvariabel; hvelvet til CI-en din injiserer dem, og Restorm leser dem. Se Hemmeligheter.

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

Parametrisere per miljø

To tilnærminger som utfyller hverandre:

1. En scenarioparameter av typen environment: --param Env=staging. Det samme scenarioet kjører mot hvilket som helst mål.
2. Enkle parametere: --param baseUrl=…, --param tenant=….

Konverteringen følger den deklarerte typen til parameteren, og en umulig konvertering får kjøringen til å feile umiddelbart i stedet for å kjøre med en gal verdi. Se Variabler og data.

Publisere loggen

--out run.log skriver loggen fortløpende. Publiser den som artefakt, også når jobben feiler — det er nettopp da du trenger den.

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

Skrive scenarioer som er lesbare i CI

Noen vaner som utgjør hele forskjellen når en rød jobb dukker opp klokka tre om natta:

• Tydelige assertion-meldinger. Feltet message i handlingen Assert er det som havner i loggen: skriv der hva du forventet.
• Logg ved de viktigste trinnene. Uten --all-logs sendes bare oppføringene fra handlingen Log: det er den røde tråden din.
• Skjemavalidering framfor assertions felt for felt. Koble errors-utgangen på Schema validate til en Log: da får du den presise listen over bruddene.
• Throw på de kritiske else-utgangene, slik at exitkoden gjenspeiler feilen.
• Retry rundt ustabile nettverkskall, framfor å godta ustabile tester. Se Kontroll.

Rydde opp

Lenk oppryddingen til done-porten på hovedscenarioet: done venter til hele undergrafen er ferdig. Se Porter og forbindelser.

Feller du bør kjenne

Felle	Løsning
Jobben venter på inndata	Oppgi alle parametere med --param; i headless modus kan ingenting spørres om
En Toast-handling vises ikke	Det er normalt: den er uten virkning i headless modus. Bruk Log
MCP-serveren dukker ikke opp	Det er tilsiktet: uten en reell skjerm starter den aldri
Exitkode 3	Tokenet eller planen — meldingen presiserer hvilket av de fire tilfellene det er
Prosjektfilen har flyttet seg	--open godtar en sti relativt til repoet: hold den relativ

Fullstendige eksempler

Pipelinene for GitHub Actions og GitLab CI ligger i Headless kjøring og CI.