12 Praktik Terbaik CI/CD untuk Pengujian API Otomatis

Pipeline hijau yang mengirimkan API yang rusak lebih buruk daripada tidak ada pipeline sama sekali. Ini memberi tahu tim Anda bahwa semuanya baik-baik saja sampai seorang pelanggan mengajukan tiket. Sebagian besar pengaturan pengujian API di CI dimulai dengan kuat dan perlahan-lahan memburuk: beberapa titik akhir tercakup, kemudian suite menjadi tidak stabil, seseorang menambahkan continue-on-error untuk menghentikan kebisingan, dan dalam waktu seperempat pengujian berjalan tetapi tidak ada yang mempercayainya. Pipeline menjadi hijau karena telah belajar mengabaikan kegagalan.

Solusinya bukan lebih banyak pengujian. Ini adalah beberapa keputusan tentang cara Anda merancang, menjalankan, dan menjaga pengujian tersebut agar tetap berfungsi di bawah tekanan dunia nyata, jenis tekanan yang berasal dari hotfix Jumat sore atau perubahan skema yang melibatkan tiga layanan. Panduan ini akan membahas dua belas keputusan tersebut, dengan konfigurasi konkret yang dapat Anda salin ke GitHub Actions, GitLab CI, atau runner apa pun yang sudah Anda gunakan.

Benang merah yang menghubungkan semuanya sama: pengujian API Anda harus berdampingan dengan kontrak API Anda, berjalan dari satu perintah portabel, dan gagal dengan keras ketika kontrak rusak. Itulah alur kerja yang akan kita bangun dengan Apidog, sebuah platform API tempat Anda merancang spesifikasi, menulis pernyataan secara visual, dan menjalankan seluruh suite secara headless di CI melalui Apidog CLI. Anda merancang pengujian sekali di aplikasi, lalu menjalankan suite yang sama persis di pipeline mana pun dengan satu perintah. Jika Anda ingin mengikuti, unduh Apidog dan siapkan API Anda sendiri.

tombol

Jika CI/CD sendiri masih baru bagi Anda, versi singkatnya adalah ini: continuous integration menjalankan pengujian Anda pada setiap commit, dan continuous delivery mempromosikan build yang melewatinya. Kami memiliki penjelasan lebih lengkap di Apa Itu CI/CD dan Bagaimana Cara Kerjanya. Sisa artikel ini mengasumsikan Anda memiliki pipeline dan ingin bagian pengujian API benar-benar mendapatkan tempatnya di dalamnya.

1. Masukkan pengujian API ke dalam pipeline, bukan di tab yang lupa Anda buka

Praktik terbaik pertama adalah yang sering dilewatkan orang: jalankan pengujian API Anda secara otomatis, pada setiap push, tanpa campur tangan manusia. Suite pengujian yang Anda jalankan secara manual sebelum rilis adalah daftar periksa, bukan jaring pengaman. Pada saat Anda ingat untuk menjalankannya, perubahan yang merusak sudah enam commit di belakang.

Hubungkan suite ke tahap yang penting. Untuk sebagian besar tim, ini terjadi pada permintaan tarik (pull requests), sehingga API yang rusak memblokir penggabungan daripada mencapai main. Berikut adalah bentuk minimal di GitHub Actions:

name: API Tests
on:
  pull_request:
    branches: [main]
jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run API test suite
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SCENARIO_ID" \
            -e "$APIDOG_ENV_ID" \
            -r cli,junit \
            --out-dir ./test-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
          SCENARIO_ID: ${{ vars.SCENARIO_ID }}
          APIDOG_ENV_ID: ${{ vars.APIDOG_ENV_ID }}

Itulah seluruh integrasinya. CLI keluar dengan kode 0 ketika setiap pernyataan lolos dan kode bukan nol ketika ada yang gagal, sehingga GitHub mengubah pekerjaan menjadi merah pada kegagalan nyata tanpa konfigurasi tambahan. Kami membahas pengaturan GitHub lengkap di Cara Mengotomatiskan Pengujian API di GitHub Actions; polanya berlaku untuk runner apa pun.

Inti dari praktik terbaik pertama adalah bahwa keputusan untuk menguji dibuat oleh mesin, bukan pengembang. Manusia lupa. Pipeline tidak.

2. Jaga agar perintah eksekusi dapat dipindahkan antar penyedia CI

Pipeline bermigrasi. Tim berpindah dari Jenkins ke GitHub Actions, menambahkan GitLab untuk repositori baru, atau menyiapkan runner yang dihosting sendiri untuk kepatuhan. Jika pengujian API Anda terpaku pada ekosistem plugin satu penyedia, setiap migrasi berarti menulis ulang pengujian tersebut.

Cara untuk menghindarinya adalah dengan menjadikan pemanggilan pengujian sebagai satu perintah shell yang dapat dipanggil oleh runner mana pun. Dengan Apidog CLI, perintah yang menjalankan suite Anda identik tidak peduli siapa yang memanggilnya:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit

Baris yang sama ini berfungsi dalam langkah run GitHub Actions, blok script GitLab, tahap shell Jenkins, atau bagian script Travis. Hanya pembungkus di sekitarnya yang berubah. GitLab, misalnya:

api-tests:
  image: node:20
  script:
    - npm install -g apidog-cli
    - apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
  artifacts:
    when: always
    reports:
      junit: ./test-results/*.xml

Karena pekerjaan berat (orkestrasi permintaan, pernyataan, resolusi lingkungan) berada di CLI dan definisi pengujian berada di Apidog, YAML pipeline Anda tetap ramping. Saat Anda beralih penyedia, Anda menyalin enam baris, bukan enam ratus. Varian Jenkins dijelaskan secara rinci di Cara Mengintegrasikan Pengujian Otomatis Apidog dengan Jenkins untuk CI/CD jika itu adalah tumpukan Anda.

3. Pastikan perilaku, bukan hanya kode status

Pengujian yang hanya memeriksa 200 OK akan lolos sementara API Anda mengembalikan array kosong, mata uang yang salah, atau nilai null di mana klien mengharapkan objek. Pengujian hanya kode status adalah alasan terbesar mengapa pipeline hijau mengirimkan respons yang rusak.

Pernyataan nyata memeriksa bentuk dan isi respons: bidang yang ada, jenisnya, nilai-nilai yang penting bagi konsumen. Di Apidog, Anda membangunnya secara visual terhadap respons, sehingga Anda menegaskan pada payload yang sebenarnya daripada menebak JSONPath di kepala Anda. Pengujian pencarian pesanan yang solid menegaskan bahwa statusnya adalah 200, order.total adalah angka, currency sama dengan nilai yang Anda kirim, dan array items tidak kosong. Masing-masing adalah pernyataan terpisah yang gagal secara independen, sehingga build merah memberi tahu Anda kontrak mana yang rusak.

Tiga aturan membuat pernyataan bertahan seiring waktu:

Tegaskan pada kontrak, bukan data. Periksa bahwa total adalah angka, bukan bahwa itu sama dengan 49.99. Nilai persis berubah; jenisnya tidak.
Satu kekhawatiran per pernyataan. Menggabungkan enam pemeriksaan ke dalam satu pernyataan menyembunyikan mana yang gagal.
Cakup jalur yang tidak bahagia. Kode 400 pada masukan yang buruk dan 401 pada token yang hilang juga merupakan bagian dari kontrak Anda. Uji bahwa mereka masih berfungsi.

Untuk pembahasan yang lebih mendalam tentang menulis pernyataan yang bertahan dari refaktor, lihat panduan kami tentang pernyataan API. Pernyataan yang kuatlah yang mengubah pengujian asap menjadi pengujian kontrak, dan pengujian kontraklah yang menangkap regresi yang penting.

4. Kelola lingkungan dan rahasia sebagai konfigurasi, bukan sebagai nilai yang dikodekan secara langsung

Pengujian Anda berjalan terhadap target yang berbeda: tumpukan lokal, API staging, titik akhir asap produksi. URL dasar, token otentikasi, dan ID tenant semuanya berubah di antara keduanya. Mengodekan salah satunya ke dalam pengujian adalah cara pengujian staging secara tidak sengaja mengenai produksi, atau cara token berakhir di riwayat git Anda.

Pertahankan lingkungan sebagai konfigurasi bernama dan suntikkan perbedaannya. Di Apidog, sebuah lingkungan menyimpan URL dasar dan variabel untuk satu target; Anda memilih mana yang digunakan oleh eksekusi CI dengan flag -e. Pipeline memasok token akses dari penyimpanan rahasianya, tidak pernah dari file di repo:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$STAGING_ENV_ID" \
  -r cli,junit

Skenario yang sama, yang diarahkan ke nilai -e yang berbeda, menjadi pengujian asap produksi Anda. Tidak ada yang berubah pada pengujian; hanya lingkungan tempat ia diselesaikan yang berubah. Simpan APIDOG_ACCESS_TOKEN di GitHub Secrets, variabel GitLab CI/CD, atau manajer kredensial runner Anda, dan referensikan berdasarkan nama. Aturannya sederhana: apa pun yang berbeda antar lingkungan atau apa pun yang rahasia adalah konfigurasi, dan konfigurasi disuntikkan saat runtime.

5. Buat pengujian deterministik agar pipeline dapat dipercaya

Pengujian yang tidak stabil (flaky) adalah pengujian yang gagal karena alasan yang tidak terkait dengan kode Anda. Ini juga merupakan cara tercepat untuk menghancurkan kredibilitas pipeline. Begitu suatu suite "terkadang gagal", pengembang mulai menjalankan ulang pekerjaan hingga menjadi hijau, yang berarti kegagalan nyata sekarang tersembunyi dalam kebisingan kegagalan palsu.

Sebagian besar ketidakstabilan pengujian API berasal dari beberapa sumber yang dapat diprediksi:

Status bersama yang dapat berubah. Dua pengujian membuat pengguna dengan email yang sama, atau satu pengujian bergantung pada data yang dihapus oleh pengujian lain. Setiap pengujian harus menyiapkan dan membersihkan datanya sendiri, atau menggunakan tenant yang terisolasi.
Asumsi waktu. Menegaskan hasil asinkron sebelum siap. Jika suatu operasi bersifat eventual, lakukan polling untuk kondisi tersebut alih-alih tidur selama beberapa detik yang tetap.
Ketergantungan nyata yang tidak Anda kontrol. Kotak pasir pembayaran pihak ketiga yang membatasi kecepatan Anda, atau layanan hulu yang sedang dalam pemeliharaan. Mock batasan tersebut sehingga pengujian Anda mengukur API Anda, bukan waktu aktif orang lain. Apidog dapat membuat mock untuk ketergantungan yang tidak stabil dari skemanya, yang menjaga ketidakstabilan eksternal dari build Anda.
Ketergantungan urutan. Pengujian yang hanya lolos ketika dijalankan dalam urutan tertentu. Sebuah suite harus lolos ketika dijalankan dalam urutan apa pun, karena runner melakukan paralelisasi.

Determinisme adalah perbedaan antara pipeline yang dihormati orang dan pipeline yang mereka hindari. Habiskan upaya rekayasa untuk itu sejak awal; pengujian yang tidak stabil akan memupuk bunga.

6. Jaga agar tahap pengujian API tetap cepat, atau pengembang akan menghindarinya

Suite pengujian yang memakan waktu dua puluh menit pada setiap permintaan tarik (pull request) menjadi beban yang dibenci pengembang dan akhirnya dinonaktifkan. Kecepatan bukanlah hal yang mewah di CI; itulah yang membuat suite tetap berjalan. Target yang diincar sebagian besar tim adalah tahap API di bawah lima menit pada PR.

Beberapa tuas untuk mencapainya:

Jalankan skenario independen secara paralel. Jika pengujian Anda deterministik (praktik terbaik lima), tidak ada yang menghentikan Anda untuk membaginya di seluruh pekerjaan paralel atau membiarkan runner menyebarkannya. Suite independen dapat berjalan berdampingan.
Tingkatkan tingkatan pengujian Anda. Jalankan suite asap cepat pada setiap PR dan suite regresi penuh saat digabungkan ke main atau pada jadwal malam. Tidak setiap pengujian perlu menjaga setiap commit.
Cache instalasi. Meng-cache instalasi npm global apidog-cli di seluruh eksekusi akan memangkas waktu penyiapan setiap pekerjaan.
Gagal cepat di mana itu membantu, selesaikan di mana itu tidak. Pada PR, berhenti pada kegagalan pertama untuk memberikan umpan balik cepat. Pada eksekusi penuh malam, gunakan --on-error continue CLI sehingga satu titik akhir yang rusak tidak menyembunyikan empat puluh lainnya yang juga rusak.

Berikut adalah pola bertingkat di GitHub Actions, dengan eksekusi asap cepat pada PR dan suite lengkap sesuai jadwal:

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'   # nightly full regression

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run suite
        run: |
          if [ "${{ github.event_name }}" = "pull_request" ]; then
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SMOKE_ID" -e "$ENV_ID" -r cli,junit --out-dir ./test-results
          else
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$FULL_ID" -e "$ENV_ID" -r cli,junit --on-error continue --out-dir ./test-results
          fi
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Tahap cepat yang berjalan lebih berharga daripada tahap menyeluruh yang dinonaktifkan.

7. Publikasikan hasil yang dapat dibaca mesin, bukan hanya segunung teks konsol

Ketika sebuah build gagal, "pengujian API gagal" tidak cukup. Anda perlu tahu pernyataan mana yang rusak, dalam skenario mana, pada permintaan mana. Build merah dengan seribu baris output konsol hampir tidak lebih baik daripada tidak ada pengujian sama sekali; seseorang masih harus membacanya.

Solusinya adalah mengeluarkan hasil dalam format yang diurai secara native oleh server CI Anda. JUnit XML adalah format standar hasil pengujian CI, dan hampir setiap platform membacanya. Apidog CLI menulisnya dengan reporter junit:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -r cli,html,junit \
  --out-dir ./test-results

Perintah tersebut mengeluarkan tiga tampilan dari eksekusi yang sama: cli untuk output konsol langsung, html untuk laporan yang dapat dijelajahi yang dapat dibuka oleh manusia, dan junit untuk mesin. Arahkan pipeline Anda ke XML dan platform mengubahnya menjadi hasil per-pengujian yang terstruktur:

      - name: Publish test report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-results
          path: ./test-results

Perhatikan if: always(). Anda ingin laporan diterbitkan bahkan ketika eksekusi gagal, karena eksekusi yang gagal adalah saat Anda benar-benar membutuhkannya. Hasilnya nyata: alih-alih "build API rusak," Anda mendapatkan "pernyataan cart-total dalam skenario checkout mulai gagal," yang mengubah sesi debugging menjadi sekilas pandang.

8. Batasi penggabungan pada suite dengan perlindungan cabang

Suite pengujian yang lolos tanpa memblokir apa pun hanyalah sebuah notifikasi. Tujuan CI adalah membuat kode yang rusak tidak dapat digabungkan, dan itu membutuhkan satu langkah lagi dari yang dikonfigurasi sebagian besar tim: perlindungan cabang.

Kode keluar melakukan pekerjaan lokal. Karena Apidog CLI keluar dengan nilai bukan nol pada setiap pernyataan yang gagal, pekerjaan menjadi merah pada kegagalan nyata. Tetapi pekerjaan merah pada PR hanya bersifat saran sampai Anda menjadikannya pemeriksaan yang wajib. Di GitHub, atur pemeriksaan API-tests sebagai pemeriksaan status wajib pada main; tombol gabung tetap dinonaktifkan sampai menjadi hijau. GitLab dan Bitbucket memiliki hal yang setara dalam pengaturan permintaan penggabungan mereka.

Ini adalah perbedaan antara suite yang menangkap regresi dan suite yang mendokumentasikannya setelah kejadian. Tanpa pemeriksaan wajib, pengembang di bawah tekanan tenggat waktu mengklik gabung dan API yang rusak dikirimkan dengan pemeriksaan merah tepat di sampingnya. Dengan gerbang, platform menolak. Pengujian berhenti menjadi saran dan menjadi aturan yang diberlakukan oleh alat untuk Anda.

Pasangkan ini dengan hasil yang dapat dibaca mesin dari praktik terbaik tujuh dan integrasi status komit, dan host Git Anda menunjukkan pemeriksaan yang gagal secara inline pada PR. Lingkaran umpan balik tertutup: push, uji, diblokir, perbaiki, hijau, gabung.

9. Hasilkan cakupan pengujian dari spesifikasi API Anda, alih-alih menulisnya secara manual

Bagian paling lambat dari pengujian API adalah menjaga pengujian tetap sinkron dengan API. Setiap titik akhir baru membutuhkan pengujian baru; setiap bidang yang berubah membutuhkan pernyataan yang diperbarui. Dilakukan secara manual, pengujian selalu tertinggal dari API, dan celah itulah tempat regresi hidup.

Langkah yang tepat adalah mendorong pengujian dari kontrak. Jika API Anda memiliki spesifikasi OpenAPI, Anda dapat membuat kerangka pengujian darinya: satu permintaan per titik akhir, dengan skema yang sudah menjelaskan bentuk respons yang diharapkan. Di Apidog, spesifikasi dan pengujian hidup di ruang kerja yang sama, sehingga skenario pengujian dapat dibangun langsung dari titik akhir yang didokumentasikan daripada ditranskripsi darinya. Kami membahas alur pembuatan di Cara Menghasilkan Koleksi Pengujian API dari Spesifikasi OpenAPI.

Ini penting dalam CI karena pengujian berbasis spesifikasi menangkap bug umum yang spesifik: perbedaan antara apa yang dijanjikan dokumen Anda dan apa yang dikembalikan API Anda. Ketika pengujian dibuat dari spesifikasi dan dijalankan terhadap API langsung, ketidakcocokan akan menyebabkan build gagal. Kontrak menjadi dapat dieksekusi. Anda masih menulis pernyataan yang mengkodekan makna bisnis secara manual, tetapi Anda tidak menulis secara manual boilerplate "apakah titik akhir ini ada dan mengembalikan bentuk yang didokumentasikan". Biarkan spesifikasi yang menanggung beban itu.

10. Gunakan pengujian berbasis data untuk mencakup kasus tepi tanpa menduplikasi skenario

Titik akhir yang sama berperilaku berbeda di berbagai input: pesanan yang valid, pesanan yang melebihi batas kredit, pesanan dengan SKU yang tidak dikenal, pesanan dalam mata uang yang tidak didukung. Menulis skenario terpisah untuk masing-masing adalah bagaimana suite membengkak menjadi ratusan pengujian yang hampir identik yang tidak ada yang memeliharanya.

Pengujian berbasis data menjalankan satu skenario terhadap banyak baris input. Anda menentukan permintaan dan pernyataan sekali, lalu memberikan tabel kasus. Apidog CLI mengambil file data dengan flag -d:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -d ./test-data/orders.csv \
  -r cli,junit \
  --out-dir ./test-results

Setiap baris di orders.csv menjadi satu iterasi dengan pass atau failnya sendiri. Satu skenario, satu pemanggilan CLI, cakupan kasus tepi penuh, dan laporan JUnit yang menunjukkan baris input mana yang gagal. Ini menjaga suite Anda tetap kecil dan cakupan Anda luas, yang persis seperti yang Anda inginkan di CI. Panduan kami tentang pengujian API berbasis data dengan CSV atau JSON membahas lebih dalam tentang struktur file data.

Pola ini paling bermanfaat pada logika validasi dan aturan harga, tempat di mana satu titik akhir memiliki cabang terbanyak dan cara terbanyak untuk mengalami regresi secara diam-diam.

11. Jalankan pengujian asap pasca-deploy terhadap lingkungan sebenarnya

Pengujian yang lolos terhadap staging memberi tahu Anda bahwa buildnya bagus. Mereka tidak memberi tahu Anda bahwa deploy berfungsi. Pergeseran konfigurasi, variabel lingkungan yang hilang, load balancer yang salah rute, sertifikat yang kedaluwarsa: semua ini melewati setiap pengujian pra-gabung dan hanya rusak di lingkungan yang sebenarnya Anda kirimkan.

Pelindungnya adalah pengujian asap yang berjalan setelah deploy, terhadap target langsung. Ini adalah suite kecil, cepat, hanya jalur kritis, alur otentikasi Anda, titik akhir baca dan tulis terpenting Anda, diarahkan ke produksi atau lingkungan yang baru saja di-deploy. Karena perintah eksekusi portabel (praktik terbaik dua) dan lingkungan hanyalah konfigurasi (praktik terbaik empat), ini adalah suite yang sama dengan -e yang berbeda:

  smoke-after-deploy:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SMOKE_SCENARIO_ID" \
            -e "$PROD_ENV_ID" \
            -r cli,junit \
            --out-dir ./smoke-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Jika pengujian asap gagal, itu adalah sinyal Anda untuk melakukan rollback sebelum pengguna menyadarinya. Untuk tim yang menjalankan deploy blue-green atau canary, Anda menjalankan suite asap terhadap warna baru sebelum mengalihkan lalu lintas ke sana, sehingga pengguna nyata pertama Anda tidak pernah menjadi orang yang menemukan deploy yang rusak. Biayanya adalah satu menit waktu pipeline. Alternatifnya adalah mengetahuinya dari tiket dukungan.

12. Perlakukan suite pengujian sebagai kode yang Anda pelihara, bukan penyiapan yang Anda selesaikan

Praktik terbaik terakhir adalah pola pikir. Suite pengujian CI bukanlah proyek yang Anda selesaikan; ini adalah aset yang Anda pelihara di samping API yang dilindunginya. Tim yang pipeline-nya tetap dapat dipercaya adalah mereka yang memperlakukan pengujian yang tidak stabil sebagai bug, tahap yang lambat sebagai technical debt, dan celah dalam cakupan sebagai regresi yang menunggu untuk terjadi.

Beberapa kebiasaan menjaga suite tetap sehat dalam jangka panjang:

Tambahkan pengujian bersamaan dengan fitur. Titik akhir baru dikirimkan dengan skenarionya dalam PR yang sama, bukan dalam tindak lanjut yang tidak pernah mendarat.
Perbaiki ketidakstabilan segera setelah muncul. Pengujian yang tidak stabil yang dikarantina adalah celah cakupan dengan lampu hijau menyala. Jangan biarkan continue-on-error menjadi permanen.
Tinjau apa yang tidak dicakup oleh suite. Secara berkala periksa titik akhir mana yang tidak memiliki pernyataan. Yang tidak teruji adalah tempat di mana pemadaman berikutnya dimulai.
Simpan konfigurasi pipeline di kontrol versi. YAML Anda, definisi lingkungan Anda, dan data pengujian Anda semuanya berada di repo, ditinjau seperti perubahan lainnya.

Karena definisi pengujian berada di Apidog dan pipeline hanya melakukan pemanggilan tipis, sebagian besar pemeliharaan ini terjadi di tempat yang mudah: Anda menambahkan skenario dan pernyataan di aplikasi, dan konfigurasi CI hampir tidak berubah. Tim yang melakukan ini dengan benar menghabiskan waktu mereka untuk meningkatkan cakupan, bukan mengawasi YAML. Untuk pandangan yang lebih luas tentang mengatur suite besar, lihat Apidog Test Suites: Cara yang Lebih Cerdas untuk Mengotomatiskan Pengujian API.

Menyatukan semuanya

Kedua belas praktik ini saling memperkuat. Perintah eksekusi portabel membuat pengujian asap pasca-deploy menjadi sepele. Pengujian deterministik membuat paralelisme aman, yang menjaga tahap tetap cepat, yang membuat pengembang menggunakannya. Hasil yang dapat dibaca mesin membuat perlindungan cabang bermakna, karena gerbang menunjuk pada pemeriksaan gagal tertentu alih-alih segunung teks. Pengujian berbasis spesifikasi dan berbasis data menjaga suite komprehensif tanpa membuatnya lambat untuk dipelihara.

Dasar umum adalah menjaga pengujian Anda tetap dekat dengan kontrak Anda dan dapat dijalankan dari satu perintah. Itulah alur kerja Apidog dalam satu kalimat: rancang API dan pengujiannya di satu tempat, lalu jalankan suite yang sama persis di pipeline mana pun dengan apidog run. CLI keluar dengan nilai bukan nol pada kegagalan, mengeluarkan JUnit untuk diurai oleh CI Anda, dan berperilaku sama apakah GitHub Actions, GitLab, Jenkins, atau runner yang dihosting sendiri yang memanggilnya.

Mulailah dari yang kecil. Hubungkan satu skenario kritis ke pipeline PR Anda dengan pernyataan nyata dan pemeriksaan status wajib. Jadikan loop itu dapat dipercaya, lalu tambahkan sisanya: eksekusi bertingkat, kasus tepi berbasis data, pengujian asap pasca-deploy. Pipeline yang Anda percaya adalah pipeline yang hanya berwarna merah ketika ada sesuatu yang benar-benar rusak, dan hanya berwarna hijau ketika benar-benar aman untuk dikirimkan. Unduh Apidog dan bangun skenario pertama hari ini.

tombol

FAQ

Apa perbedaan antara pengujian API di CI dan CI/CD? CI (continuous integration) menjalankan pengujian API Anda secara otomatis pada setiap commit atau pull request untuk menangkap regresi lebih awal. CD (continuous delivery) mempromosikan build ke target deploy setelah melewati pemeriksaan tersebut. Pengujian API berada di keduanya: suite pra-gabung menjaga integrasi, dan suite asap pasca-deploy memverifikasi pengiriman. Perintah Apidog CLI yang sama melayani kedua tahap.

Apakah saya perlu menulis kode untuk menjalankan pengujian API dalam pipeline? Tidak. Anda membangun permintaan dan pernyataan secara visual di Apidog, lalu menjalankannya secara headless dengan satu perintah apidog run. Pipeline hanya membutuhkan satu perintah itu, yang menjaga konfigurasi CI Anda tetap ramping dan berarti insinyur QA dapat mengelola pengujian tanpa memelihara kerangka kerja berbasis kode. Penjelasan lengkapnya ada di Cara Mengotomatiskan Pengujian API di CI/CD.

Bagaimana cara menghentikan pengujian API saya agar tidak tidak stabil di CI? Tiga penyebab terbesar adalah data pengujian yang dapat berubah yang dibagikan, asumsi waktu pada operasi asinkron, dan dependensi pihak ketiga yang tidak terkontrol. Beri setiap pengujian datanya sendiri, lakukan polling untuk kondisi asinkron alih-alih tidur selama waktu yang tetap, dan mock batasan eksternal yang tidak Anda kontrol. Suite yang lolos dalam urutan apa pun dan pada setiap eksekusi adalah tujuannya.

Bagaimana cara membuat pengujian API yang gagal memblokir penggabungan? Dua bagian. Pertama, test runner harus keluar dengan nilai bukan nol pada kegagalan; Apidog CLI melakukan ini pada setiap pernyataan yang gagal, sehingga pekerjaan menjadi merah secara otomatis. Kedua, tandai pekerjaan itu sebagai pemeriksaan status wajib dalam aturan perlindungan cabang host Git Anda. Tombol gabung tetap dinonaktifkan sampai pemeriksaan lolos.

Bisakah saya menjalankan pengujian API yang sama di GitHub Actions, GitLab, dan Jenkins? Ya. Karena logika pengujian berada di Apidog dan pipeline hanya memanggil apidog run, perintahnya identik di seluruh penyedia; hanya YAML atau skrip pipeline di sekitarnya yang berubah. Portabilitas itulah yang membuat migrasi penyedia CI menjadi pengeditan enam baris alih-alih penulisan ulang. Lihat Cara Mengotomatiskan Pengujian API di GitHub Actions untuk pengaturan khusus GitHub.

Seberapa cepat tahap pengujian API saya harus berjalan? Targetkan di bawah lima menit pada permintaan tarik (pull requests). Capai ini dengan menjalankan suite asap cepat pada PR dan suite regresi penuh setiap malam, memparalelkan skenario independen, dan meng-cache instalasi CLI. Tahap yang lambat adalah tahap yang pada akhirnya dinonaktifkan pengembang, yang mengalahkan tujuan.