API-tesztek automatizálása folyamatos integrációban

A felületen felépített forgatókönyv változtatás nélkül fut a pipeline-ban is. Ez az útmutató a méretezéssel foglalkozik.

Előfeltételek

• Pro vagy Enterprise előfizetés.
• Egy szervezeti token (rstk_…), amely a CI titkos széfjébe kerül. (A token önkiszolgáló előállítása az irányítópultról hamarosan elérhető lesz.)

Az alapelv

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

Kilépési kód: 0 = siker, 1 = a forgatókönyv hibája, 2 = hívási hiba, 3 = megtagadott jogosultság.

Virtuális megjelenítő kell hozzá

A Restorm asztali alkalmazás: ablak nélkül is szükség van egy megjelenítőkiszolgálóra. Linuxos runneren az xvfb-run -a előtaggal kell indítani.

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

A titkok

Titkot soha nem szabad a projektbe írni. Az érzékeny változókat a környezeti változó titokforrással kell deklarálni: a CI széfje injektálja őket, a Restorm pedig beolvassa. Lásd: Titkok.

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

Paraméterezés környezet szerint

Két egymást kiegészítő megközelítés:

1. Egy environment típusú forgatókönyv-paraméter: --param Env=staging. Ugyanaz a forgatókönyv bármelyik célpont ellen lefut.
2. Egyszerű paraméterek: --param baseUrl=…, --param tenant=….

Az átalakítás a paraméter deklarált típusát követi, és egy lehetetlen átalakítás azonnal megbuktatja az indítást, ahelyett hogy hibás értékkel futna le. Lásd: Változók és adatok.

A napló közzététele

A --out run.log menet közben írja a naplót. Érdemes artefaktumként közzétenni, akkor is, amikor a feladat elbukik — épp ilyenkor van rá igazán szükség.

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

Olvasható forgatókönyvek CI-hez

Néhány szokás, amely mindent megváltoztat, amikor hajnali 3-kor felbukkan egy piros feladat:

• Beszédes állítási üzenetek. Az Assert művelet message mezője kerül a naplóba: ide azt érdemes beírni, amit a teszt elvárt.
• Napló a kulcslépéseknél. --all-logs nélkül csak a Log művelet bejegyzései kerülnek ki: ez adja a futtatás elbeszélő fonalát.
• Sémaellenőrzés mezőnkénti állítások helyett. A Schema validate errors kimenetét egy Log műveletre kötve pontos listát ad a szabálysértésekről.
• Throw a kritikus else kimenetekre, hogy a kilépési kód tükrözze a hibát.
• Retry az instabil hálózati hívások körül, ahelyett hogy szeszélyes teszteket kellene elfogadni. Lásd: Vezérlés.

Takarítás

A takarítást a fő forgatókönyv done portjára érdemes fűzni: a done megvárja, hogy a teljes részgráf befejeződjön. Lásd: Portok és társítások.

Ismert csapdák

Csapda	Megoldás
A feladat bemenetre vár	Adja meg minden paramétert a --param argumentummal; headless módban semmi nem kérdezhető meg
Egy Toast művelet nem jelenik meg	Ez normális: headless módban nincs hatása. Helyette a Log művelet használandó
Az MCP-kiszolgáló nem jelenik meg	Ez szándékos: valódi kijelző nélkül soha nem indul el
3-as kilépési kód	A token vagy az előfizetés — az üzenet megmondja, a négy eset közül melyik
A projektfájl elmozdult	A --open a tárházhoz képest relatív útvonalat is elfogad: érdemes relatívan hagyni

Teljes példák

A GitHub Actions és GitLab CI pipeline-ok itt találhatók: Headless futtatás és CI.