Saat saya menjalankan contract test Specmatic terhadap klon Zerodha berbasis MERN-stack yang saya anggap “selesai”, alat tersebut menandai lima cacat nyata yang tidak pernah tertangkap oleh pengecekan manual saya. Dari 178 kasus uji yang dihasilkan, rangkaian pengujian tersebut merusak API dengan cara yang akan berdampak pada pengguna asli—tipe data yang tidak valid, crash pada kredensial yang salah format, korupsi data secara diam-diam, pendaftaran yang tidak idempotent, dan perubahan kontrak yang merusak yang menghentikan gerbang CI seketika.

Bagaimana bug tersebut lolos dari pengujian manual

Proyek ini menggabungkan backend Node.js, frontend React, penyimpanan MongoDB, dan Razorpay untuk pembayaran. Saya mencoba alur pendaftaran dan pembayaran secara manual dan semuanya tampak berfungsi. Namun, pengujian manual hanya menguji happy path: ia mengonfirmasi bahwa kode berperilaku baik saat pengguna mengikuti langkah-langkah yang dimaksudkan. Hal ini tidak membuktikan bahwa layanan dapat bertahan dari permintaan yang salah format atau perilaku klien yang tidak terduga.

Saat saya mengarahkan Specmatic ke kode yang ada, kontrak—deskripsi eksplisit dari bentuk request dan response setiap endpoint—berfungsi sebagai source of truth. Alat tersebut kemudian secara otomatis menghasilkan matriks skenario positif dan negatif yang masif, yang banyak di antaranya tidak akan pernah terpikirkan untuk ditulis oleh penguji manusia.

Lima cacat yang terungkap

  • Celah validasi input – Endpoint /newOrder menerima angka desimal dan string untuk field quantity, padahal kontrak mengharuskan integer. Tes yang dihasilkan yang mengirimkan tipe data yang salah menyebabkan API berperilaku tidak semestinya.
  • Error login yang tidak tertangani – Memberikan kredensial yang salah format ke rute autentikasi memicu pengecualian runtime karena kode kekurangan pengecekan tipe data.
  • Korupsi pembayaran secara diam-diam – Endpoint /verify-payment mengizinkan nilai boolean untuk amount. Ketika nilai true lolos, database mencatat pembayaran berhasil dengan nilai nol, yang secara diam-diam menggelembungkan angka pendapatan.
  • Kurangnya idempotensi – Menjalankan alur pendaftaran untuk kedua kalinya dalam rangkaian pengujian gagal, karena endpoint mencoba membuat ulang pengguna yang sudah ada alih-alih menangani duplikasi tersebut dengan baik.
  • Perubahan kontrak yang merusak terdeteksi – Saya sengaja mengubah tipe data dalam kontrak. Pipeline CI segera menolak perubahan tersebut, mencegah rilis yang merusak.

Mengapa contract testing penting untuk pipeline CI

  • Pengujian negatif dalam skala besar – Sebagian besar dari 178 kasus adalah input edge-case. Menulisnya secara manual akan memakan waktu yang sangat lama.
  • Keamanan bagi klien pihak ketiga – Kontrak mendefinisikan apa yang dijanjikan layanan kepada konsumen eksternal. Jika implementasi menyimpang, contract test akan gagal, sehingga melindungi aplikasi downstream.
  • Loop umpan balik yang cepat – Gerbang CI menghentikan perubahan yang merusak sebelum sempat digabungkan (merged), menyelamatkan tim dari rollback yang mahal.
  • Peningkatan kualitas kode – Menambahkan endpoint actuator dan membuat alur pendaftaran menjadi idempotent adalah langkah-langkah yang diperlukan agar kontrak dapat diuji, yang pada gilirannya memperkuat layanan tersebut.

Kompromi yang harus dipertimbangkan pengembang

Contract testing menambah beban pemeliharaan. Spesifikasi harus tetap sinkron dengan kode, dan proses pembuatan tes dapat memperlama waktu build. Tim perlu memutuskan apakah keamanan tambahan tersebut sebanding dengan upaya ekstra yang dikeluarkan, terutama untuk proyek yang lebih kecil di mana pengujian manual terasa sudah cukup.

Apa yang perlu diperhatikan selanjutnya

  • Adopsi CI yang lebih luas – Seiring semakin banyak tim yang mengintegrasikan rangkaian kontrak ke dalam pipeline mereka, perangkat pendukung kemungkinan akan menjadi lebih cepat dan lebih mudah dikonfigurasi.
  • Format kontrak yang terstandarisasi – Spesifikasi yang muncul dapat memudahkan berbagi kontrak antar layanan dan tim.
  • Otomatisasi pembaruan spesifikasi – Alat yang menyimpulkan kontrak dari perubahan kode dapat mengurangi beban pemeliharaan manual.

Jika Anda berasumsi API Anda sudah kokoh karena UI berjalan lancar, menjalankan contract test dapat mengungkap kesalahan tersembunyi yang terlewatkan oleh pengecekan manual. Menambahkan kontrak yang dapat dieksekusi ke dalam pipeline CI Anda mengubah status “tampak baik” menjadi “terbukti aman.”

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