Pengujian dalam Arsitektur Microservice: Consumer Driven Contract

Pada tulisan sebelumnya, kita telah melihat bagaimana arsitektur backend Blibli.com berkembang. Meskipun sedang bergerak ke arah event-first development, mayoritas sistem di Blibli.com sekarang merupakan gabungan dari banyak microservices yang masih menggunakan model api-first development.

Ketika berhadapan dengan banyak (baca: ratusan) microservice, salah satu masalah utama yang dihadapi adalah sulitnya menjaga konsistensi dalam melakukan testing. Misalnya, pada umumnya jika kita memiliki sebuah service yang akan memanggil service lain seperti berikut:

Service A memanggil Service B melalui HTTP

Terdapat banyak cara untuk melakukan pengujian terhadap Service A (Consumer). Salah satu cara yang paling sederhana adalah dengan menyiapkan sebuah sistem percobaan Service B (Producer), dengan data yang juga merupakan data sampel, dan kemudian menjalankan berbagai rangkaian pengujian terhadap sistem percobaan ini. Model pengujian ini jarang dilakukan untuk sistem pengujian otomatis, karena:

• Data sampel yang digunakan sangat sulit dijaga baik dari segi model data yang sesuai ataupun konsistensi. Pembaharuan sistem atau pengujian oleh orang atau sistem lain sangat mungkin akan menyebabkan perubahan data, yang tentunya akan seringkali membuat pengujian gagal karena ekspektasi dan realita yang telah berubah. Tanpa adanya konsistensi data, maka hasil pengujian juga tidak akan bisa konsisten.
• Ketergantungan pengembang (developer) ataupun penguji (tester) terhadap sistem percobaan ini dapat dengan mudah membuat tambahan beban bagi tiga pihak: pengembang Producer, Consumer, dan penguji. Memastikan ketiga pihak ini selalu berada di satu posisi yang sama akan memakan banyak waktu dan tenaga.

Untuk menanggulangi berbagai masalah yang umum ditemui ini maka dikembangkan lah cara lain, yakni melakukan pengujian Consumer dengan membuat Producer palsu yang selalu mengembalikan nilai yang diinginkan (dan valid) ketika dipanggil dengan parameter tertentu. Teknik ini dikenal dengan nama stubbing.

Proses Stubbing

Stub biasanya dibuat di dalam kode pengujian pada Consumer, dan akan meniru apa yang seharusnya dikembalikan oleh Producer ketika Consumer melakukan pemanggilan. Karena yang melakukan pengujian adalah Consumer, biasanya Consumer hanya akan melakukan pengujian sesuai dengan kebutuhannya. Producer mungkin saja memiliki 10 fungsi, tetapi jika Consumer hanya menggunakan 3 dari 10 fungsi tersebut, maka Consumer hanya akan melakukan stubbing terhadap 3 fungsi yang dibutuhkannya.

Selama mengimplementasikan mode pengujian seperti ini pada Blibli.com, kami menemukan beberapa masalah yang menghambat kecepatan pengembangan, misalnya:

1. Karena tidak ada ikatan antara pengujian Producer dan Consumer secara otomatis, potensi terjadinya perbedaan antara test dan sistem berjalan (production) sangat besar. Jika Producer melakukan perubahan tanpa memberitahu Consumer, sistem Consumer dapat berhenti bekerja (rusak) pada sistem berjalan walaupun berhasil menjalankan semua test.
2. Karena banyaknya jumlah backend service di Blibli.com, sulit bagi sebuah Producer untuk mengetahui secara pasti siapa saja yang menggunakan setiap fungsinya, serta bagaimana fungsinya digunakan. Satu fungsi Producer dapat saja digunakan oleh beberapa Consumer sekaligus, dengan ekspektasi yang berbeda-beda dari masing-masing Consumer. Ketika Producer melakukan pembaharuan, kita tidak ingin pembaharuan tersebut bekerja di satu Consumer tetapi merusak sistem Consumer lain. Hal ini sulit dipastikan jika Producer tidak mengetahui siapa pengguna fungsinya serta bagaimana fungsi tersebut digunakan.

Ilustrasi perbedaan antara lingkungan testing dan production

Kesulitan koordinasi dan sinkronisasi informasi ini sangat umum ditemukan pada sebuah organisasi yang telah bertumbuh besar, dengan puluhan atau ratusan tim independen, yang masing-masing memiliki ruang gerak dan ritme kerja yang berbeda-beda.

Bahkan di Proyek non-Software

Untungnya, karena hal ini merupakan permasalahan umum, telah banyak solusi yang ditawarkan untuk menyelesaikan masalah ini. Salah satu solusi untuk permasalahan ini yaitu Consumer Driven Contract.

Consumer Driven Contract

Secara sederhana, Consumer Driven Contract adalah pola pengembangan sistem di mana setiap Consumer menuliskan ekspektasi dan kebutuhannya kepada Producer di dalam bentuk kontrak. Kontrak ini akan digunakan oleh Producer sebagai dasar pengembangan, agar Producer dapat mengetahui siapa yang menggunakan sistemnya, serta bagaimana sistem tersebut digunakan.

Kontrak antar Producer dan Consumer ini menjadi pusat pengembangan, dan akan secara otomatis memberikan stub ke Consumer dan rangkaian test ke Producer untuk memastikan kedua belah pihak memenuhi kontrak. Dengan adanya kontrak ini, ketika Producer melakukan pembaharuan, ia akan dapat langsung mengetahui siapa saja yang terpengaruh, dan jika perubahan tanpa merusak tidak dapat dihindari, Consumer yang terkait dapat dihubungi atau perubahan tersebut dapat dihindari dan didiskusikan lebih lanjut.

Ilustrasi Komponen yang Terlibat dalam Consumer Driven Contract

Mengingat bahwa Blibli.com dikembangkan dengan menggunakan teknologi Java dan komitmen Blibli.com pada Open Source, maka dipilihlah Spring Cloud Contract (SCC) sebagai framework untuk Consumer Driven Contract di Blibili.com. Setelah melakukan eksperimen internal, berkontribusi ke SCC menyesuaikan kebutuhan Blibli.com, yaitu:

1. Menambahkan dukungan terhadap HTTP Cookie di dalam kontrak untuk mendukung sistem session di Blibli.com, dan
2. Mengambil fitur upload file dari versi baru untuk dimasukkan ke versi sebelumnya, yang digunakan di Blibli.com.

Untuk menjadi warga di dunia teknologi yang baik, Blibli.com berkomitmen untuk terus berkontribusi dan mengembangkan berbagai teknologi yang digunakan secara langsung, baik dalam bentuk kode, artikel pengetahuan, ataupun jurnal akademik.

Kembali ke topik SCC, saat ini SCC sudah mulai diadopsi secara penuh di Blibli.com. Blibli.com sedang menjalani proses adopsi di seluruh service yang ada, untuk memastikan stabilitas dan kualitas Blibli.com yang diberikan ke pengguna terus meningkat.

Pada artikel ini tidak akan dibahas detail implementasi dan lessons learned dalam implementasi SCC. Nantikan artikel berikutnya untuk membahas Spring Cloud Contract secara mendalam, mengapa kita menggunakan Consumer Driven Contract bukan dokumentasi API, serta apa saja masalah yang dihadapi selama implementasi beserta dengan solusi-solusinya!

Tertarik menyelesaikan masalah yang berhubungan dengan pengujian dan kualitas perangkat lunak? Ingin menjadi bagiandalam pengembangan sistem yang besar dan kompleks? Ingin ikut terlibat dalam dunia open source? Memiliki saran atau masukan untuk artikel ini atau ide topik untuk artikel berikutnya? Silahkan email ke alex.sim@gdn-commerce.com untuk berbincang-bincang ataupun menjajaki kemungkinan untuk bergabung dengan kami!