在持續整合中自動化 API 測試
在介面裡建構好的情境，可以原封不動地在您的管線中執行。本指南談的是規模化的部分。
- 一個 Pro 或 Enterprise 方案。
- 一個組織權杖（
rstk_…），放進您 CI 的密鑰保險庫。（從儀表板自助建立這個 權杖的功能即將推出。）
RESTORM_TOKEN=$RESTORM_TOKEN restorm \ --open ./api.restorm \ --run "Tests de fumée" \ --headless \ --all-logs \ --out run.log \ --param baseUrl=$BASE_URL結束代碼 0 = 成功，1 = 情境失敗，2 = 呼叫方式錯誤，3 = 權限被拒。
需要一個虛擬顯示器
Section titled “需要一個虛擬顯示器”Restorm 是一套桌面應用程式：即使不顯示視窗，它還是需要一個顯示伺服器。在 Linux
runner 上，請在前面加上 xvfb-run -a。
xvfb-run -a restorm --open ./api.restorm --run "Tests de fumée" --headless永遠不要把密鑰寫進專案。請用環境變數這種密鑰來源宣告您的敏感變數；由您 CI 的 保險庫注入，Restorm 再讀取它們。請參閱密鑰。
env: API_TOKEN: ${{ secrets.API_TOKEN }}依環境參數化
Section titled “依環境參數化”兩種互補的做法：
- 一個情境參數，型別為
environment：--param Env=staging。同一個情境就能 對任何目標執行。 - 一般的參數：
--param baseUrl=…、--param tenant=…。
轉換會依照參數宣告的型別進行；一旦無法轉換，啟動會立刻失敗，而不是帶著錯誤 的值繼續執行。請參閱 情境中的變數與資料。
--out run.log 會把記錄逐步寫出。請把它發佈為產出物，就算作業失敗也要發佈 —
那正是它最有用的時候。
- uses: actions/upload-artifact@v4 if: always() with: name: journal-restorm path: run.log撰寫在 CI 裡讀得懂的情境
Section titled “撰寫在 CI 裡讀得懂的情境”幾個習慣，會在凌晨三點看到一個紅色作業時徹底改變局面：
- 寫清楚斷言訊息。
Assert 動作的
message欄位， 就是會出現在記錄裡的那段文字：請把原本預期的結果寫進去。 - 在關鍵步驟留下記錄。 不加
--all-logs時，只有 Log 動作的項目會被 輸出：那就是您的敘事主線。 - 用結構驗證取代逐欄斷言。 把
Schema validate 的
errors輸出接到一個 Log 上：您就會拿到一份精確的違規清單。 - 在關鍵的
else輸出上接 Throw，讓結束代碼能反映失敗。 - 在不穩定的網路呼叫外面包一層 Retry，而不是容忍時好時壞的測試。請參閱 控制。
請把清理動作接在主情境的 done 連接埠上：done 會等到整個子圖都結束。
請參閱連接埠與連結。
需要知道的陷阱
Section titled “需要知道的陷阱”| 陷阱 | 解法 |
|---|---|
| 作業卡在等待輸入 | 請用 --param 提供所有參數；在 headless 模式下，任何東西都無法向使用者詢問 |
| Toast 動作沒有顯示 | 這是正常的：它在 headless 模式下不會有作用。請改用 Log |
| MCP 伺服器沒有出現 | 這是刻意的：沒有真正的顯示器時，它永遠不會啟動 |
結束代碼 3 | 不是權杖就是方案 — 訊息會指明是四種情況中的哪一種 |
| 專案檔案的位置變了 | --open 接受相對於儲存庫的路徑：請讓它保持相對 |
GitHub Actions 與 GitLab CI 的管線都在 headless 執行與 CI 裡。