Automatizarea testelor de API în integrare continuă

Un scenariu construit în interfață rulează ca atare în pipeline-ul dumneavoastră. Ghidul de față acoperă trecerea la scară.

Cerințe prealabile

• Un plan Pro sau Enterprise.
• Un token de organizație (rstk_…), de pus în seiful de secrete al sistemului dumneavoastră de CI. (Crearea acestui token în autoservire, din tabloul de bord, urmează în curând.)

Principiul

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

Cod de ieșire 0 = succes, 1 = eșec al scenariului, 2 = eroare de invocare, 3 = drept refuzat.

Este necesar un afișaj virtual

Restorm este o aplicație desktop: chiar și fără fereastră, are nevoie de un server de afișare. Pe un runner Linux, adăugați prefixul xvfb-run -a.

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

Secretele

Nu scrieți niciodată un secret în proiect. Declarați variabilele sensibile cu sursa de secret variabilă de mediu; seiful sistemului dumneavoastră de CI le injectează, iar Restorm le citește. Vedeți Secrete.

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

Parametrizarea pe medii

Două abordări complementare:

1. Un parametru de scenariu tipizat environment: --param Env=staging. Același scenariu rulează împotriva oricărei ținte.
2. Parametri simpli: --param baseUrl=…, --param tenant=….

Conversia urmează tipul declarat al parametrului, iar o conversie imposibilă face să eșueze lansarea imediat, în loc să ruleze cu o valoare greșită. Vedeți Variabile și date.

Publicarea jurnalului

--out run.log scrie jurnalul pe măsură ce se produce. Publicați-l ca artefact, inclusiv atunci când jobul eșuează — tocmai atunci este util.

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

Scrierea unor scenarii lizibile în CI

Câteva obiceiuri care schimbă totul când apare un job roșu la 3 dimineața:

• Mesaje de aserțiune explicite. Câmpul message al acțiunii Aserțiune este ceea ce va apărea în jurnal: scrieți acolo ce se aștepta.
• Jurnal la etapele-cheie. Fără --all-logs, sunt emise numai intrările acțiunii Log: acesta este firul dumneavoastră narativ.
• Validare de schemă, mai degrabă decât aserțiune câmp cu câmp. Conectați ieșirea errors a acțiunii Validează o schemă la un Log: obțineți lista precisă a încălcărilor.
• Throw pe ieșirile else critice, pentru ca codul de ieșire să reflecte eșecul.
• Retry în jurul apelurilor de rețea instabile, în loc să acceptați teste intermitente. Vedeți Control.

Curățarea

Înlănțuiți curățarea pe portul done al scenariului principal: done așteaptă ca tot subgraful să se fi terminat. Vedeți Porturi și legături.

Capcane de știut

Capcană	Soluție
Jobul așteaptă o introducere de date	Furnizați toți parametrii cu --param; în mod headless nu se poate cere nimic
O acțiune Toast nu se afișează	Este normal: nu are efect în mod headless. Folosiți Log
Serverul MCP nu apare	Este voit: fără un afișaj real, nu pornește niciodată
Ieșire 3	Tokenul sau planul — mesajul precizează care dintre cele patru cazuri
Fișierul de proiect s-a mutat	--open acceptă o cale relativă la depozit: păstrați-o relativă

Exemple complete

Pipeline-urile GitHub Actions și GitLab CI se află în Rulare headless și CI.