API-testien automatisointi jatkuvassa integraatiossa

Käyttöliittymässä rakennettu skenaario toimii sellaisenaan putkessasi. Tämä opas käsittelee siirtymistä tuotantomittakaavaan.

Edellytykset

• Pro- tai Enterprise-tilaustaso.
• Organisaatiotoken (rstk_…), joka sijoitetaan CI:si salaisuusholviin. (Tokenin luominen itsepalveluna hallintapaneelista on tulossa pian.)

Periaate

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

Poistumiskoodi 0 = onnistuminen, 1 = skenaarion epäonnistuminen, 2 = kutsuvirhe, 3 = oikeus evätty.

Virtuaalinäyttö on välttämätön

Restorm on työpöytäsovellus: myös ilman ikkunaa se tarvitsee näyttöpalvelimen. Linux-ajurilla lisää eteen xvfb-run -a.

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

Salaisuudet

Älä koskaan kirjoita salaisuutta projektiin. Määrittele arkaluonteiset muuttujasi salaisuuslähteellä ympäristömuuttuja; CI:si holvi syöttää ne, ja Restorm lukee ne. Katso Salaisuudet.

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

Parametrointi ympäristöittäin

Kaksi toisiaan täydentävää lähestymistapaa:

1. environment-tyyppinen skenaarioparametri: --param Env=staging. Sama skenaario ajetaan mitä tahansa kohdetta vastaan.
2. Yksinkertaiset parametrit: --param baseUrl=…, --param tenant=….

Muunnos noudattaa parametrin ilmoitettua tyyppiä, ja mahdoton muunnos kaataa käynnistyksen välittömästi sen sijaan, että suoritus tapahtuisi väärällä arvolla. Katso Muuttujat ja data.

Lokin julkaiseminen

--out run.log kirjoittaa lokin reaaliajassa. Julkaise se artefaktina myös silloin, kun työ epäonnistuu — juuri silloin siitä on hyötyä.

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

CI:ssä luettavien skenaarioiden kirjoittaminen

Muutama tapa, joka muuttaa kaiken, kun punainen työ ilmestyy kello kolme yöllä:

• Selkeät väittämäviestit. Toiminnon Assert kenttä message on se, mikä näkyy lokissa: kirjoita siihen, mitä odotettiin.
• Loki avainvaiheissa. Ilman --all-logs-argumenttia vain toiminnon Log merkinnät lähetetään: se on kertova punainen lankasi.
• Skeeman validointi kenttäkohtaisen väittämän sijaan. Kytke toiminnon Schema validate lähtö errors Log-toimintoon: saat tarkan luettelon rikkomuksista.
• Throw kriittisissä else-lähdöissä, jotta poistumiskoodi heijastaa epäonnistumista.
• Retry epävakaiden verkkokutsujen ympärille sen sijaan, että hyväksyisit satunnaisesti epäonnistuvat testit. Katso Ohjaus.

Siivoaminen

Ketjuta siivous pääskenaarion porttiin done: done odottaa, että koko aligraafi on valmis. Katso Portit ja kytkennät.

Tunnettuja sudenkuoppia

Sudenkuoppa	Ratkaisu
Työ jää odottamaan syötettä	Anna kaikki parametrit --param-argumentilla; headless-tilassa mitään ei voi kysyä
Toast-toiminto ei näy	Se on normaalia: sillä ei ole vaikutusta headless-tilassa. Käytä Log
MCP-palvelin ei ilmesty	Se on tarkoituksellista: ilman todellista näyttöä se ei käynnisty koskaan
Poistuminen koodilla 3	Token tai tilaustaso — viesti täsmentää, kummasta neljästä tapauksesta on kyse
Projektitiedosto on siirtynyt	--open hyväksyy repositorioon nähden suhteellisen polun: pidä se suhteellisena

Täydelliset esimerkit

GitHub Actions- ja GitLab CI -putket löytyvät sivulta Headless-suoritus ja jatkuva integraatio.