Automatyzacja testów API w ciągłej integracji

Scenariusz zbudowany w interfejsie działa w potoku bez żadnych zmian. Ten przewodnik omawia przejście na większą skalę.

Wymagania wstępne

• Plan Pro albo Enterprise.
• Token organizacji (rstk_…), który należy umieścić w sejfie sekretów używanego systemu CI. (Samoobsługowe tworzenie tego tokenu z panelu pojawi się wkrótce.)

Zasada działania

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

Kod wyjścia 0 = sukces, 1 = niepowodzenie scenariusza, 2 = błąd wywołania, 3 = brak uprawnień.

Potrzebny jest wirtualny ekran

Restorm jest aplikacją desktopową: nawet bez okna potrzebuje serwera ekranu. Na runnerze linuksowym trzeba poprzedzić polecenie prefiksem xvfb-run -a.

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

Sekrety

Sekretu nigdy nie należy zapisywać w projekcie. Zmienne wrażliwe deklaruje się ze źródłem sekretu zmienna środowiskowa; sejf systemu CI je wstrzykuje, a Restorm je odczytuje. Zob. Sekrety.

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

Parametryzacja według środowiska

Dwa uzupełniające się podejścia:

1. Parametr scenariusza typu environment: --param Env=staging. Ten sam scenariusz działa wobec dowolnego celu.
2. Zwykłe parametry: --param baseUrl=…, --param tenant=….

Konwersja przebiega zgodnie z zadeklarowanym typem parametru, a konwersja niemożliwa powoduje natychmiastowe niepowodzenie uruchomienia, zamiast wykonania z błędną wartością. Zob. Zmienne i dane.

Publikowanie dziennika

--out run.log zapisuje dziennik na bieżąco. Warto publikować go jako artefakt, również wtedy, gdy zadanie kończy się niepowodzeniem — właśnie wtedy jest najbardziej przydatny.

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

Pisanie scenariuszy czytelnych w CI

Kilka nawyków, które robią ogromną różnicę, gdy czerwone zadanie pojawia się o trzeciej w nocy:

• Jednoznaczne komunikaty asercji. Pole message akcji Assert jest tym, co pojawi się w dzienniku: warto wpisać tam, czego oczekiwano.
• Dziennik w kluczowych krokach. Bez --all-logs emitowane są wyłącznie wpisy akcji Log: to główna nić narracji.
• Walidacja schematu zamiast asercji pole po polu. Wyjście errors bloku Walidacja schematu warto podłączyć do Log: powstaje wtedy dokładna lista naruszeń.
• Throw na krytycznych wyjściach else, aby kod wyjścia odzwierciedlał niepowodzenie.
• Retry wokół niestabilnych wywołań sieciowych, zamiast godzenia się na niestabilne testy. Zob. Sterowanie.

Porządkowanie

Porządkowanie należy podłączyć do portu done głównego scenariusza: done czeka, aż cały podgraf zostanie zakończony. Zob. Porty i połączenia.

Pułapki, o których warto wiedzieć

Pułapka	Rozwiązanie
Zadanie czeka na wprowadzenie danych	Należy podać wszystkie parametry przez --param; w trybie headless nie da się o nic zapytać
Akcja Toast nie pojawia się	To normalne: w trybie headless nie ma ona żadnego efektu. Zamiast niej służy Log
Serwer MCP się nie pojawia	Tak ma być: bez rzeczywistego ekranu nigdy się nie uruchamia
Wyjście 3	Token albo plan — komunikat wskazuje, o który z czterech przypadków chodzi
Plik projektu został przeniesiony	--open przyjmuje ścieżkę względną wobec repozytorium: warto zachować ją względną

Kompletne przykłady

Potoki GitHub Actions i GitLab CI opisuje strona Uruchamianie headless i CI.