Temuduga Backend: Bagaimanakah anda menggunakan ujian kontrak didorong pengguna untuk mengeluarkan API perkhidmatan mikro dengan selamat?

Maklum balas dan skop

Penyedia pesanan melayani pengguna web, mudah alih dan tak segerak. Pasukan ingin mengesan perubahan pemecah (breaking changes) sebelum mengeluarkan penyedia, tanpa memulakan setiap perkhidmatan sebenar untuk setiap komit. Reka bentuk aliran kerja kontrak didorong pengguna: perkara yang ditulis oleh pengguna, cara penyedia mengesahkan, cara broker memilih versi, cara provider states berfungsi dan masa penggunaan (deployment) dibenarkan.

Ini menguji sempadan API, pelapisan ujian, keserasian versi dan penghantaran berterusan. Pact memodelkan kontrak sebagai permintaan yang diperlukan oleh pengguna dan respons minimum, kemudian memainkannya semula terhadap penyedia; ia tidak menggantikan ujian unit, integrasi atau hujung ke hujung (end-to-end).

Perkara yang diuji oleh penemuduga

Sama ada tingkah laku pengguna menjadi kontrak interaksi minimum dan bukannya salinan pelaksanaan penyedia.
Sama ada anda boleh menyambungkan ujian olok-olok pengguna, pengesahan penyedia, broker dan matriks penggunaan.
Sama ada provider states mengasingkan prasyarat tanpa susunan pangkalan data yang dikongsi atau kelayakan pengeluaran.
Sama ada anda mengendalikan berbilang versi pengguna, kontrak yang belum disahkan, kontrak mesej dan pengunduran (rollback).

Soalan untuk dijelaskan terlebih dahulu

Adakah antara muka tersebut HTTP, pemesejan tak segerak, atau kedua-duanya? Pembawa kontrak adalah berbeza.
Medan manakah yang sebenarnya digunakan oleh pengguna? Kontrak harus menyatakan permintaan yang diperlukan dan respons minimum.
Bolehkah provider states mencipta, membersihkan dan memparameterkan data ujian? Kebergantungan manakah yang memerlukan stub?
Bagaimanakah versi dikenal pasti, dan gabungan pengguna/penyedia manakah yang mesti lulus sebelum pengeluaran?
Adakah terdapat broker, penandaan cawangan (branch tagging), dasar pakatan belum selesai (pending pacts) dan strategi pengunduran?

Rangka kerja jawapan 30 saat

Pengguna menulis ujian interaksi terhadap olok-olok Pact, menghasilkan kontrak dengan hanya penegasan permintaan dan respons yang diperlukan; mereka menerbitkannya ke broker. Pengesah penyedia memilih versi pengguna sasaran, menyediakan provider states, memainkan semula permintaan dalam persekitaran yang terpencil dan menerbitkan keputusan. Get penggunaan CI menyemak matriks versi sebenar; kontrak baharu yang belum disahkan boleh ditangguhkan atau menyekat keluaran. Kontrak membuktikan bentuk mesej dan interaksi, bukan semua ketepatan perniagaan. Sekiranya berlaku kegagalan, hentikan penggunaan, betulkan penyedia atau undurkan ke versi yang lulus matriks.

Jawapan langkah demi langkah

1. Tentukan interaksi daripada tingkah laku pengguna

Setiap interaksi menerangkan kaedah, laluan, pengepala yang diperlukan, medan permintaan penting dan penegasan respons minimum. Ujian pengguna memanggil olok-olok Pact dan bukannya penyedia sebenar, menghasilkan kontrak yang pantas dan boleh dikongsi yang terikat dengan penggunaan sebenar pengguna.

text

consumer test -> pact file -> broker
provider verifier + provider state -> replay -> verification result
deployment gate -> compatible version matrix -> deploy or block

2. Pastikan kontrak kekal minimum dan stabil

Jangan menegaskan medan respons yang tidak digunakan, ID rawak atau snapshot pangkalan data yang lengkap. Gunakan matcher untuk jenis, format dan struktur yang diperlukan; sahkan hanya bentuk cap masa dinamik dan UUID. Ujian kontrak menumpukan pada mesej komunikasi, bukan fungsi generik penyedia.

3. Reka bentuk provider states

Provider state ialah prasyarat interaksi, seperti "pesanan telah dibayar." Pengendali keadaan mencipta atau menyediakan stub data sebelum pengesahan dan membersihkannya selepas itu. Parameter mestilah boleh dikesan dan idempoten tanpa kelayakan pengeluaran; interaksi tidak seharusnya bergantung pada urutan yang tidak terkawal.

4. Urus versi dan pengesahan dalam broker

Pengguna menerbitkan kontrak dengan label cawangan, versi atau persekitaran. Penyedia mengesahkan versi pengguna yang dipilih dan menerbitkan keputusan. Get penggunaan menyemak penyedia calon terhadap pengguna yang sebenarnya akan dijalankan, bukan sekadar sama ada "latest" berwarna hijau. Tingkah laku pending membolehkan kontrak baharu disahkan dan direkodkan sebelum memutuskan sama ada untuk menyekat.

5. Pilih susunan pelancaran dan tetingkap keserasian

Untuk perubahan yang serasi, gunakan penyedia yang memahami permintaan lama dan mengembalikan respons yang boleh dibaca oleh pengguna lama, kemudian tingkatkan pengguna. Perubahan pemecah memerlukan bacaan/tulisan dwi, laluan berversi atau tetingkap penghijrahan. Message pacts mengesahkan port mesej, tetapi penghantaran broker sebenar, percubaan semula dan penyusunan masih memerlukan ujian berasingan.

6. Kendalikan kegagalan dan perhatikan pengeluaran

Rekod interaksi yang gagal, provider state, versi, SHA komit dan persekitaran. Sekat penggunaan dan undurkan ke versi terakhir yang lulus matriks; selepas keluaran, perhatikan ralat 4xx/5xx, ralat penyahsiri, dead letters dan metrik perniagaan. Ujian kontrak hijau tidak membuktikan ketepatan pengeluaran, jadi kekalkan perlindungan masa jalan (runtime).

Contoh jawapan berkualiti tinggi

Setiap pengguna akan menulis interaksi sebenar terhadap olok-olok Pact, menjana kontrak dengan hanya permintaan yang diperlukan dan respons minimum serta menerbitkannya ke broker. Pengesah penyedia memilih versi pengguna, menjalankan provider states yang boleh diulang secara terpencil, memainkan semula permintaan dan menerbitkan keputusan dengan versi penyedia dan SHA komit. Get CI menyemak sama ada versi pengguna/penyedia yang akan dijalankan bersama mempunyai bukti pengesahan; pending pacts membolehkan kontrak baharu disahkan tanpa memecahkan penyedia lama serta-merta.

Kontrak merangkumi bentuk komunikasi dan medan yang digunakan, bukan semua ujian unit, integrasi, hujung ke hujung atau perniagaan. Lancarkan pembaca sebelum pemutus penulis: pastikan penyedia serasi dengan permintaan dan respons lama, kemudian hijrahkan pengguna; gunakan laluan berversi atau tetingkap dwi-tulis untuk perubahan pemecah. Sekiranya berlaku kegagalan, sekat keluaran dan kembali ke matriks lulus terakhir sambil mengekalkan pemantauan ralat masa jalan, dead-letter dan metrik perniagaan. Message pacts meliputi kandungan mesej, manakala semantik broker memerlukan ujian berasingan.

Mod kegagalan biasa

Menjadikan kontrak sebagai snapshot respons penyedia penuh supaya medan yang tidak berkaitan menyekat keluaran.
Menjalankan olok-olok pengguna sahaja dan tidak pernah memainkan semula kontrak terhadap penyedia.
Menjadikan provider states bergantung pada susunan pangkalan data yang dikongsi, data rawak atau kelayakan pengeluaran.
Menyemak versi terkini sahaja dan terlepas matriks penggunaan sebenar serta klien ekor panjang (long-tail).
Memperlakukan Pact sebagai ujian hujung ke hujung dan mengabaikan broker sebenar, kebenaran, prestasi dan peraturan perniagaan.
Menggunakan perisian selepas kegagalan pengesahan atau ketiadaan versi pengunduran yang boleh disahkan.

Soalan susulan dan jawapan rujukan

Mengapa perlu memastikan jangkaan respons minimum?

Pengguna hanya perlu mengunci medan yang mereka gunakan. Jangkaan minimum mengurangkan gandingan yang tidak disengajakan dan membolehkan penyedia menambah medan yang tidak berkaitan dengan selamat.

Bagaimanakah provider state berbeza daripada lekapan ujian (test fixture)?

Provider state ialah antara muka prasyarat yang boleh dilaksanakan yang boleh disediakan dan dibersihkan oleh pengesah dalam persekitaran penyedia. Lekapan hanyalah artifak data dan mungkin tidak mewujudkan keadaan rentas perkhidmatan dengan betul.

Apakah masalah yang diselesaikan oleh pending pact?

Ia membolehkan kontrak baharu memasuki broker dan disahkan tanpa menggagalkan binaan penyedia lama serta-merta pada kali pertama kontrak itu muncul tanpa disahkan. Sama ada untuk mendayakannya adalah dasar keluaran organisasi.

Bagaimanakah anda menghalang pertambahan kontrak yang tidak terkawal (contract sprawl)?

Nyahduplikasi interaksi pengguna sebenar, hentikan versi lama, hadkan medan rawak dan snapshot penuh, serta rekod pemilik, versi dan masa pengesahan terakhir dalam broker.

Mengapakah pemilihan versi pengguna penting?

Get mesti mengesahkan versi yang akan dijalankan bersama. Menyemak main atau latest sahaja boleh terlepas versi mudah alih atau cawangan lama yang masih dalam pengeluaran.

Bolehkah Pact membuktikan ketepatan perniagaan penyedia?

Tidak. Ia membuktikan bahawa interaksi memenuhi kontrak pengguna. Invarian perniagaan, prestasi, kebenaran, pemulihan dan infrastruktur sebenar masih memerlukan ujian lain dan pemerhatian pengeluaran.