Sebaik sahaja saya menjalankan ujian kontrak Specmatic terhadap klon Zerodha berasaskan MERN-stack saya yang "siap", alat tersebut telah mengesan lima kecacatan sebenar yang tidak pernah dikesan oleh semakan manual saya. Daripada 178 kes ujian yang dijana, set ujian tersebut merosakkan API dalam cara yang akan menjejaskan pengguna sebenar—jenis data yang tidak sah, kegagalan (crash) pada kredential yang salah format, kerosakan data senyap, pendaftaran yang tidak bersifat idempotan, dan perubahan kontrak yang merosakkan sistem yang menghentikan proses CI serta-merta.

Bagaimana pepijat terlepas daripada ujian manual

Projek ini menggabungkan backend Node.js, frontend React, storan MongoDB, dan Razorpay untuk pembayaran. Saya telah melakukan aliran pendaftaran dan pembayaran secara manual dan semuanya kelihatan berfungsi. Walau bagaimanapun, ujian manual hanya menguji "happy path": ia mengesahkan kod berfungsi apabila pengguna mengikut langkah-langkah yang ditetapkan. Ia tidak membuktikan perkhidmatan tersebut mampu bertahan daripada permintaan yang salah format atau tingkah laku klien yang tidak dijangka.

Apabila saya mengarahkan Specmatic ke arah kod sedia ada, kontrak tersebut—iaitu huraian eksplisit bagi bentuk permintaan (request) dan respons setiap endpoint—berfungsi sebagai sumber kebenaran (source of truth). Alat tersebut kemudian menjana matriks senario positif dan negatif yang besar secara automatik, yang mana kebanyakannya tidak akan terfikir untuk ditulis oleh penguji manusia.

Lima kecacatan yang ditemui

  • Jurang pengesahan input – Endpoint /newOrder menerima nombor perpuluhan dan string untuk medan quantity, walaupun kontrak memerlukan integer. Ujian yang dijana yang menghantar jenis data yang salah menyebabkan API tidak berfungsi dengan betul.
  • Ralat log masuk yang tidak dikendalikan – Memasukkan kredential yang salah format ke laluan (route) pengesahan mencetuskan pengecualian masa larian (runtime exception) kerana kod tersebut kekurangan semakan jenis data.
  • Kerosakan pembayaran senyap – Endpoint /verify-payment membenarkan nilai boolean untuk amount. Apabila nilai true terlepas masuk, pangkalan data merekodkan pembayaran berjaya dengan nilai sifar, secara senyap meningkatkan angka hasil (revenue).
  • Ketiadaan idempotensi – Menjalankan aliran pendaftaran buat kali kedua dalam set ujian gagal, kerana endpoint tersebut cuba mencipta semula pengguna sedia ada dan bukannya mengendalikan pertindihan tersebut dengan betul.
  • Perubahan kontrak yang merosakkan dikesan – Saya sengaja mengubah jenis data dalam kontrak. Saluran paip (pipeline) CI menolak perubahan tersebut dengan serta-merta, sekali gus menghalang pelepasan (release) yang boleh merosakkan sistem.

Mengapa ujian kontrak penting untuk saluran paip CI

  • Ujian negatif pada skala besar – Kebanyakan daripada 178 kes tersebut adalah input kes hujung (edge-case). Menulis kes-kes tersebut secara manual akan memakan masa yang terlalu lama.
  • Keselamatan untuk klien pihak ketiga – Kontrak menentukan apa yang dijanjikan oleh sesuatu perkhidmatan kepada pengguna luaran. Jika pelaksanaan lari daripada kontrak, ujian kontrak akan gagal, sekali gus melindungi aplikasi hiliran (downstream apps).
  • Gelung maklum balas pantas – Pintu gerbang CI menghentikan perubahan yang merosakkan sebelum ia boleh digabungkan (merged), menyelamatkan pasukan daripada proses rollback yang kosnya tinggi.
  • Kualiti kod yang dipertingkatkan – Menambah endpoint actuator dan menjadikan aliran pendaftaran bersifat idempotan adalah langkah perlu untuk menjadikan kontrak boleh diuji, yang seterusnya memperkukuh perkhidmatan tersebut.

Pertimbangan yang perlu dinilai oleh pembangun

Ujian kontrak menambah beban penyelenggaraan. Spesifikasi mesti sentiasa selari dengan kod, dan proses penjanaan ujian boleh memanjangkan masa binaan (build times). Pasukan perlu memutuskan sama ada keselamatan tambahan tersebut berbaloi dengan usaha ekstra yang diberikan, terutamanya untuk projek kecil di mana ujian manual dirasakan sudah mencukupi.

Apa yang perlu diperhatikan seterusnya

  • Penerapan CI yang lebih meluas – Apabila lebih banyak pasukan menyepadukan set kontrak ke dalam saluran paip mereka, peralatan kemungkinan besar akan menjadi lebih pantas dan lebih boleh dikonfigurasi.
  • Format kontrak yang standard – Spesifikasi yang sedang muncul boleh memudahkan perkongsian kontrak merentasi perkhidmatan dan pasukan.
  • Automasi kemas kini spesifikasi – Alat yang membuat inferens kontrak daripada perubahan kod boleh mengurangkan beban penyelenggaraan manual.

Jika anda menganggap API anda mantap hanya kerana UI berjalan lancar, menjalankan ujian kontrak boleh mendedahkan kerosakan tersembunyi yang terlepas daripada semakan manual. Menambah kontrak yang boleh dilaksanakan (executable contract) ke dalam saluran paip CI anda mengubah status "kelihatan baik" kepada "terbukti selamat."

Repository: https://github.com/priya3054/zerodha-specmatic