Mengotomatiskan pengujian API dalam integrasi berkelanjutan

Sebuah skenario yang dibangun di dalam antarmuka berjalan apa adanya di dalam pipeline Anda. Panduan ini membahas peningkatan skalanya.

Prasyarat

• Sebuah paket Pro atau Enterprise.
• Sebuah token organisasi (rstk_…) yang diletakkan di dalam brankas rahasia CI Anda. (Pembuatan token ini secara mandiri dari dasbornya akan segera hadir.)

Prinsipnya

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

Kode keluar 0 = berhasil, 1 = skenarionya gagal, 2 = galat pemanggilannya, 3 = hak ditolak.

Sebuah tampilan virtual dibutuhkan

Restorm adalah aplikasi desktop: bahkan tanpa jendela, ia tetap memerlukan sebuah server tampilan. Pada runner Linux, awali dengan xvfb-run -a.

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

Rahasia

Jangan pernah menuliskan sebuah rahasia di dalam proyeknya. Deklarasikan variabel sensitif Anda dengan sumber rahasia variabel lingkungan; brankas CI Anda menyuntikkannya, dan Restorm membacanya. Lihat Rahasia.

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

Memparameterkan menurut lingkungan

Dua pendekatan yang saling melengkapi:

1. Sebuah parameter skenario bertipe environment: --param Env=staging. Skenario yang sama berjalan terhadap sasaran mana pun.
2. Parameter sederhana: --param baseUrl=…, --param tenant=….

Konversinya mengikuti tipe yang dideklarasikan untuk parameternya, dan konversi yang tidak mungkin dilakukan akan langsung menggagalkan peluncurannya alih-alih menjalankannya dengan nilai yang keliru. Lihat Variabel dan data.

Menerbitkan lognya

--out run.log menulis lognya secara berkelanjutan. Terbitkanlah sebagai artefak, termasuk ketika job-nya gagal — justru di situlah ia berguna.

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

Menulis skenario yang mudah dibaca di CI

Beberapa kebiasaan yang sangat menentukan ketika sebuah job merah muncul pukul tiga pagi:

• Pesan asersi yang jelas. Kolom message pada aksi Asersi adalah yang akan muncul di dalam lognya: tuliskan di sana apa yang diharapkan.
• Log pada langkah-langkah kunci. Tanpa --all-logs, hanya entri aksi Log yang dipancarkan: itulah benang naratif Anda.
• Validasi skema alih-alih asersi kolom demi kolom. Sambungkan keluaran errors milik Memvalidasi sebuah skema ke sebuah Log: Anda memperoleh daftar pelanggarannya secara persis.
• Throw pada keluaran else yang kritis, agar kode keluarnya mencerminkan kegagalannya.
• Retry di sekitar panggilan jaringan yang tidak stabil, alih-alih menerima pengujian yang kadang lolos kadang tidak. Lihat Kendali.

Membersihkan

Rangkaikan pembersihannya pada port done milik skenario utamanya: done menunggu hingga seluruh sub-grafnya selesai. Lihat Port dan sambungan.

Jebakan yang perlu diketahui

Jebakan	Solusi
Job-nya menunggu sebuah masukan	Berikan semua parameternya dengan --param; dalam mode headless, tidak ada yang bisa ditanyakan
Sebuah aksi Toast tidak muncul	Itu wajar: aksi itu tidak berefek dalam mode headless. Gunakan Log
Server MCP-nya tidak muncul	Itu disengaja: tanpa tampilan sungguhan, ia tidak pernah dijalankan
Keluaran 3	Tokennya atau paketnya — pesannya menjelaskan mana di antara keempat kasusnya
File proyeknya berpindah	--open menerima jalur yang relatif terhadap repositorinya: pertahankan tetap relatif

Contoh lengkap

Pipeline GitHub Actions dan GitLab CI ada di Eksekusi headless dan CI.