Contract testing memeriksa apakah provider dan consumer masih memenuhi kesepakatan tentang request, response, event, tipe, aturan wajib, dan perilaku error. Ia memberi feedback lebih cepat daripada menunggu pengujian end-to-end lengkap, tetapi tidak menggantikan uji jaringan, database nyata, atau proses bisnis.
Apa yang termasuk dalam kontrak?
Kontrak mencakup lebih dari nama field. Ia menjelaskan tipe, format, required atau optional, nullable, rentang, enum, identitas, status, dan struktur error. Perilaku juga penting: apakah operasi idempoten, apakah hasil langsung final, dan apa arti data kosong. Asumsi yang tidak tertulis tidak dapat diuji.
Spesifikasi seperti OpenAPI memberi deskripsi interface HTTP yang dapat dibaca manusia dan mesin. Namun, schema tidak menjamin seluruh aturan bisnis. Mulailah dari alasan kontrak data dibuat sebelum payload.
Apa beda schema, provider, dan consumer test?
| Jenis | Pertanyaan | Batas |
|---|---|---|
| Schema validation | Apakah bentuk sesuai aturan? | Tidak membuktikan perilaku layanan |
| Provider test | Apakah layanan menghasilkan kontrak? | Belum membuktikan asumsi consumer |
| Consumer test | Apakah data contoh dapat dipakai? | Dapat memakai mock yang tidak realistis |
| Integration test | Apakah komponen nyata bekerja bersama? | Lebih lambat dan mahal |
Contoh apa yang menghasilkan pengujian bernilai?
Gunakan nilai minimum, maksimum, null, field hilang, enum tidak dikenal, array kosong, object bertingkat, karakter Unicode, decimal presisi, serta error yang diharapkan. Untuk perubahan, jalankan kontrak consumer lama terhadap provider baru. Happy path tunggal hanya membuktikan contoh itu sendiri.
Contoh harus aman dan representatif. Gunakan prinsip sample payload yang baik serta test data aman. Hindari menyalin payload production yang mengandung identitas atau rahasia.
Bagaimana menempatkan contract test pada alur perubahan?
Provider menerbitkan perubahan kontrak dalam pull request. Test memeriksa schema dan contoh, lalu consumer penting menjalankan assertion yang relevan. Perubahan breaking harus berhenti atau masuk proses versioning. Hasil test disimpan bersama versi kontrak agar kegagalan dapat ditelusuri.
- Usulkan.
Jelaskan perubahan dan dampaknya.
- Verifikasi.
Jalankan provider dan consumer contracts.
- Uji nyata.
Gunakan environment integrasi.
- Rilis bertahap.
Pantau hasil dan rollback boundary.
Kegagalan apa yang sering luput?
- Mock consumer menerima nilai yang parser nyata tolak.
- Schema benar tetapi makna field berubah.
- Error response tidak ikut dikontrak.
- Urutan array dianggap penting tanpa dokumentasi.
- Precision angka berbeda antar-runtime.
- Test lulus tetapi versi yang dideploy berbeda.
Pasangkan dengan API versioning agar hasil gagal menghasilkan keputusan migrasi, bukan sekadar pengecualian test.
Bagaimana contract testing membantu workflow visual?
Kontrak dapat menjadi dasar field picker, validasi, sample, dan mapping. Namun hasil impor tetap perlu ditinjau karena schema database tidak selalu menjelaskan makna bisnis atau enum. Workflow yang terhubung ke banyak consumer harus menyimpan asumsi yang mudah ditemukan oleh reviewer.
NitroNet dapat dievaluasi untuk manfaat desain dan pengujian workflow, tetapi artikel ini tidak mengungkap implementasi internal. Uji kontrak pada boundary publik yang didukung, lalu lanjutkan dengan production readiness review. Contract test yang hijau adalah bukti penting, bukan izin otomatis untuk rilis.
Simpan kontrak sebagai satu paket versioned yang dapat dijalankan oleh provider dan consumer. Paket tidak perlu berisi data rahasia. Ia harus cukup kaya untuk membedakan schema valid, perilaku benar, serta perubahan yang memerlukan koordinasi.
- Sertakan schema request, response sukses, dan seluruh kelas error yang digunakan consumer.
- Tambahkan contoh valid minimum, maksimum, null, kosong, enum baru, serta object bertingkat.
- Nyatakan precision angka, timezone, encoding, urutan, pagination, dan perilaku field yang tidak dikenal.
- Tulis assertion semantik untuk total, status, idempotensi, dan apakah hasil langsung bersifat final.
- Hubungkan setiap consumer penting dengan subset kontrak yang benar-benar dipakainya.
- Jalankan paket pada commit provider dan consumer, kemudian simpan versi artefak hasil.
- Tolak perubahan breaking tanpa versioning atau acknowledgment dari pemilik yang terdampak.
- Pertahankan integration test nyata untuk jaringan, autentikasi, database, serta efek bisnis.
Paket ini mengurangi perdebatan berdasarkan contoh informal. Ketika test gagal, tampilkan aturan, versi provider, consumer terdampak, dan perubahan yang menyebabkannya. Jangan memperbarui snapshot hanya untuk membuat pipeline hijau; perubahan expectation adalah perubahan kontrak yang membutuhkan review.
Susun suite berdasarkan perilaku, bukan hanya bentuk payload. Uji nilai minimum dan maksimum, field opsional yang hilang, null, enum tidak dikenal, precision angka, timezone, duplikat, serta urutan event. Untuk setiap kegagalan, jelaskan apakah producer atau consumer yang melanggar dan siapa pemilik perbaikannya. Jalankan kontrak yang sama pada kandidat rilis serta lingkungan representatif. Simpan versi kontrak bersama bukti hasil agar tim dapat membedakan regresi baru dari perbedaan yang memang sudah disetujui.