Petunjuk dan cakupan
Sebuah penyedia layanan pesanan (order provider) melayani konsumen web, seluler, dan asinkron. Tim ingin mendeteksi breaking changes sebelum merilis penyedia layanan tersebut, tanpa harus menjalankan setiap layanan nyata untuk setiap commit. Rancang alur kerja kontrak berbasis konsumen: apa yang ditulis konsumen, bagaimana penyedia memverifikasi, bagaimana broker memilih versi, bagaimana provider states bekerja, dan kapan deployment diizinkan.
Ini menguji batas-batas API, pelapisan pengujian, kompatibilitas versi, dan continuous delivery. Pact memodelkan kontrak sebagai permintaan yang diwajibkan oleh konsumen dan respons minimal, lalu memutarnya kembali (replay) ke penyedia; ini tidak menggantikan pengujian unit, integrasi, atau end-to-end.
Apa yang dinilai oleh pewawancara
- Apakah perilaku konsumen menjadi kontrak interaksi minimal, bukan salinan dari implementasi penyedia.
- Apakah Anda dapat menghubungkan pengujian mock konsumen, verifikasi penyedia, broker, dan matriks deployment.
- Apakah provider states mengisolasi prasyarat tanpa ketergantungan urutan database bersama atau kredensial produksi.
- Apakah Anda menangani beberapa versi konsumen, kontrak yang belum diverifikasi, kontrak pesan, dan rollback.
Pertanyaan klarifikasi di awal
- Apakah antarmukanya HTTP, pengiriman pesan asinkron, atau keduanya? Media pembawa kontraknya berbeda.
- Field mana yang benar-benar digunakan oleh konsumen? Kontrak harus menyatakan permintaan yang diperlukan dan respons minimal.
- Bisakah provider states membuat, membersihkan, dan memparameterkan data pengujian? Dependensi mana yang perlu di-stub?
- Bagaimana versi diidentifikasi, dan kombinasi konsumen/penyedia mana yang harus lolos sebelum masuk ke produksi?
- Apakah ada broker, penandaan cabang (branch tagging), kebijakan pending pact, dan strategi rollback?
Kerangka jawaban 30 detik
Konsumen menulis pengujian interaksi terhadap mock Pact, menghasilkan kontrak yang hanya berisi asersi permintaan dan respons yang diperlukan; mereka memublikasikannya ke broker. Verifikator penyedia memilih versi konsumen target, menyiapkan provider states, memutar ulang permintaan di lingkungan yang terisolasi, dan memublikasikan hasilnya. CI deployment gate memeriksa matriks versi yang sebenarnya; kontrak baru yang belum diverifikasi dapat berstatus pending atau memblokir rilis. Kontrak membuktikan bentuk pesan dan interaksi, bukan seluruh kebenaran bisnis. Jika terjadi kegagalan, hentikan deployment, perbaiki penyedia, atau lakukan rollback ke versi yang lolos matriks.
Jawaban langkah demi langkah
1. Tentukan interaksi dari perilaku konsumen
Setiap interaksi menjelaskan metode, path, header yang diperlukan, field permintaan penting, dan asersi respons minimal. Pengujian konsumen memanggil mock Pact alih-alih penyedia sebenarnya, menghasilkan kontrak yang cepat dan dapat dibagikan yang terikat pada penggunaan konsumen yang sebenarnya.
consumer test -> pact file -> broker
provider verifier + provider state -> replay -> verification result
deployment gate -> compatible version matrix -> deploy or block2. Jaga agar kontrak tetap minimal dan stabil
Jangan membuat asersi untuk field respons yang tidak digunakan, ID acak, atau snapshot database lengkap. Gunakan matcher untuk tipe data, format, dan struktur yang diperlukan; validasi hanya bentuk (shape) dari timestamp dinamis dan UUID. Pengujian kontrak berfokus pada pesan komunikasi, bukan fungsionalitas umum penyedia.
3. Rancang provider states
Provider state adalah prasyarat interaksi, seperti "pesanan telah dibayar". Handler state membuat atau melakukan stub data sebelum verifikasi dan membersihkannya setelahnya. Parameter harus dapat dilacak dan idempoten tanpa kredensial produksi; interaksi tidak boleh bergantung pada urutan yang tidak terkontrol.
4. Kelola versi dan verifikasi dalam broker
Konsumen memublikasikan kontrak dengan label cabang, versi, atau lingkungan. Penyedia memverifikasi versi konsumen yang dipilih dan memublikasikan hasilnya. Deployment gate memeriksa penyedia kandidat terhadap konsumen yang benar-benar akan berjalan bersama, bukan sekadar melihat apakah status "latest" berwarna hijau. Perilaku pending memungkinkan kontrak baru diverifikasi dan dicatat sebelum memutuskan apakah akan memblokir rilis.
5. Pilih urutan peluncuran dan jendela kompatibilitas
Untuk perubahan yang kompatibel, deploy penyedia yang memahami permintaan lama dan mengembalikan respons yang dapat dibaca konsumen lama, kemudian perbarui konsumen. Breaking changes memerlukan dual reads/writes, path berversi, atau jendela migrasi. Message pacts memvalidasi port pesan, tetapi pengiriman broker nyata, percobaan ulang (retries), dan pengurutan tetap memerlukan pengujian terpisah.
6. Tangani kegagalan dan amati produksi
Catat interaksi yang gagal, provider state, versi, commit SHA, dan lingkungan. Blokir deployment dan lakukan rollback ke versi terakhir yang lolos matriks; setelah rilis, pantau error 4xx/5xx, error deserialisasi, dead letters, dan metrik bisnis. Pengujian kontrak yang berstatus hijau tidak membuktikan kebenaran produksi, jadi pertahankan perlindungan saat runtime.
Contoh jawaban berkualitas tinggi
Setiap konsumen akan menulis interaksi nyata terhadap mock Pact, menghasilkan kontrak yang hanya memuat permintaan yang diperlukan dan respons minimal, lalu memublikasikannya ke broker. Verifikator penyedia memilih versi konsumen, menjalankan provider states yang dapat diulang secara terisolasi, memutar ulang permintaan, dan memublikasikan hasilnya beserta versi penyedia dan commit SHA. CI gate memeriksa apakah versi konsumen/penyedia yang akan berjalan bersama memiliki bukti verifikasi; pending pacts memungkinkan kontrak baru diverifikasi tanpa langsung merusak penyedia lama.
Kontrak mencakup bentuk komunikasi dan field yang digunakan, bukan semua pengujian unit, integrasi, end-to-end, atau bisnis. Luncurkan reader sebelum mengubah writer secara tidak kompatibel: jaga agar penyedia tetap kompatibel dengan permintaan dan respons lama, lalu migrasikan konsumen; gunakan path berversi atau jendela dual-write untuk breaking changes. Jika terjadi kegagalan, blokir rilis dan kembali ke matriks terakhir yang berhasil sambil tetap memantau runtime error, antrean pesan gagal (dead-letter), dan metrik bisnis. Message pacts mencakup konten pesan, sementara semantik broker memerlukan pengujian terpisah.
Pola kegagalan umum
- Menjadikan kontrak sebagai snapshot respons penyedia secara penuh sehingga field yang tidak terkait memblokir rilis.
- Hanya menjalankan mock konsumen dan tidak pernah memutar ulang kontrak terhadap penyedia.
- Membuat provider states bergantung pada urutan database bersama, data acak, atau kredensial produksi.
- Hanya memeriksa versi terbaru (latest) dan melewatkan matriks deployment nyata serta klien long-tail.
- Memperlakukan Pact sebagai pengujian end-to-end dan mengabaikan broker nyata, otorisasi, kinerja, dan aturan bisnis.
- Melakukan deployment setelah kegagalan verifikasi atau tidak memiliki versi rollback yang dapat diverifikasi.
Pertanyaan lanjutan dan jawaban referensi
Mengapa ekspektasi respons harus dijaga tetap minimal?
Konsumen seharusnya hanya mengunci field yang mereka gunakan. Ekspektasi minimal mengurangi kopling yang tidak disengaja dan memungkinkan penyedia menambahkan field yang tidak terkait dengan aman.
Apa perbedaan antara provider state dan test fixture?
Provider state adalah antarmuka prasyarat yang dapat dieksekusi, yang dapat disiapkan dan dibersihkan oleh verifikator di lingkungan penyedia. Fixture hanyalah artefak data dan mungkin tidak membangun state lintas-layanan dengan benar.
Masalah apa yang diselesaikan oleh pending pact?
Fitur ini memungkinkan kontrak baru masuk ke broker dan diverifikasi tanpa langsung menggagalkan build penyedia lama saat pertama kali kontrak tersebut muncul tanpa verifikasi. Pengaktifannya bergantung pada kebijakan rilis organisasi.
Bagaimana cara mencegah penumpukan kontrak yang tidak terkontrol (contract sprawl)?
Hapus duplikasi interaksi konsumen yang nyata, hentikan versi lama, batasi field acak dan snapshot penuh, serta catat pemilik, versi, dan waktu verifikasi terakhir di broker.
Mengapa pemilihan versi konsumen itu penting?
Gate harus memverifikasi versi-versi yang akan berjalan bersamaan. Hanya memeriksa branch main atau latest dapat melewatkan versi aplikasi seluler atau branch lama yang masih aktif di produksi.
Bisakah Pact membuktikan kebenaran bisnis dari penyedia?
Tidak. Pact hanya membuktikan bahwa interaksi memenuhi kontrak konsumen. Invarian bisnis, performa, otorisasi, pemulihan bencana, dan infrastruktur nyata tetap memerlukan pengujian lain serta observasi di lingkungan produksi.