BDD - pengembangan melalui perilaku. BDD untuk layanan mikro adalah kolaborasi dari klien, pengembang, dan penguji. BDD adalah pengembangan yang memperhitungkan kepentingan teknis dan persyaratan bisnis. Pendekatan ini biasanya digunakan untuk menggambarkan antarmuka aplikasi, dan karena microservices adalah detail dari implementasi sistem, BDD juga cocok untuk mengembangkan microservices. Bagaimana melakukannya - dalam terjemahan Ken Pugh.
Tentang Pengarang: Ken Pugh mengajarkan perusahaan untuk mengembangkan fleksibilitas, menciptakan sistem berkualitas tinggi menggunakan Acceptance Test-Driven Development, BDD, akselerasi DevOps. Ken telah menulis beberapa buku tentang pengembangan perangkat lunak, adalah pemenang Prefaktoring Jolt Award 2006, salah satu pencipta kursus Rekayasa Perangkat Lunak Agile SAFe.
Perilaku dalam BDD sering diungkapkan oleh konstruksi Given / When / Then. Kita diberikan keadaan tertentu ketika suatu tindakan atau peristiwa terjadi, maka keadaan tersebut berubah dan / atau informasi dikembalikan.
Misalnya, logika kewarganegaraan, seperti aturan dan perhitungan bisnis, cukup menjelaskan konversi input ke output.
Desain Berorientasi Antarmuka menggunakan prinsip
"desain untuk antarmuka, bukan implementasi .
" Konsumen layanan menggunakan antarmuka yang disediakannya, bukan internal. Ini berarti bahwa antarmuka seperti itu harus dipikirkan dengan jelas, termasuk perilaku kesalahan. Untuk definisi istilah dalam deskripsi antarmuka atau perilakunya, dimungkinkan untuk menggunakan DDD - Domain Driven Design.
Layanan microsoft dapat sinkron ketika konsumen
secara langsung memanggil layanan lain dan mengharapkan hasilnya, atau asinkron ketika
layanan menjawab pesan bahwa klien telah menempatkan dalam antrian .
Pertimbangkan contoh layanan sinkron.
Layanan sinkron
Bayangkan sebuah layanan yang menghitung diskon pesanan penjualan. Seluruh proses adalah serangkaian operasi terkait.
Perilaku layanan ini dapat digambarkan sebagai berikut:
Get discount for a customer Given these inputs Customer category Order Amount Then service outputs Discount Amount
Layanan dapat menghitung diskon menggunakan algoritma dalam kode, berdasarkan pada basis data data lokal atau dengan menghubungi layanan lain.
Itu dapat menggunakan JSON atau XML sebagai format pesan. Namun, mendeskripsikan layanan tanpa menentukan detail implementasi membantu memisahkan semantik operasi dari sintaks.
Apa perilakunya?
Dengan menggunakan BDD, Anda dapat mulai mendesain dengan data sampel untuk mendapatkan gambaran tentang perilaku yang diinginkan. Pengembang layanan, klien, dan penguji dapat memberikan contoh ini. Dua kolom pertama adalah input ke layanan, dan kolom di sebelah kanan adalah output.
Contoh ini menunjukkan istilah domain yang mungkin memerlukan penyempurnaan lebih lanjut - misalnya, uraikan nilai yang valid.
Dipahami bahwa layanan mengembalikan hasil yang benar jika data input masuk dalam kisaran nilai yang dapat diterima.
Deskripsi perilaku, terutama untuk layanan-layanan mikro, sering menyertakan respons jika terjadi kegagalan dan kesalahan. Deskripsi potensi kegagalan membantu konsumen memahami apa yang harus dilakukan dalam kasus-kasus tersebut. Pelanggan layanan dapat menggunakan perpustakaan khusus, misalnya, Hystrix dari Netflix, untuk memperbaiki beberapa kegagalan ini.
Beberapa potensi kesalahan layanan kami:
Kegagalan dapat dinyatakan sebagai konstanta numerik atau karakter dalam protokol komunikasi.
Menggunakan nama-nama yang bermakna dalam BDD membantu menekankan semantik kegagalan, bukan sintaksisnya.
Jika nilai yang diberikan sebagai kategori tidak ada dalam daftar nilai yang dapat diterima, maka layanan akan mengembalikan indikator kegagalan: "Nilai parameter kueri tidak valid." Ini dapat diwakili, misalnya, dengan mengembalikan kode HTTP 400 dan deskripsi teks yang sesuai.
Atau, Anda dapat menentukan nilai diskon yang akan dikembalikan, misalnya 0 jika salah satu parameter salah. Dalam hal ini, layanan harus bertanggung jawab untuk merekam masalah ini sehingga konsekuensinya dapat dianalisis.
Layanan BDD test dapat membentuk konteks untuk tes unitnya. Dalam proses desain,
tanggung jawab untuk lulus tes BDD terletak pada kelas dan metode . Tes unit menentukan tanggung jawab ini.
Rintisan bertopik
Saat menguji suatu layanan, bertopik layanan yang bergantung yang sering diminta. Mereka sangat dibutuhkan untuk layanan yang lambat, mahal atau acak. Jika perilaku layanan diskon tidak pernah berubah, maka saat menguji klien, Anda dapat menggunakan instance pertempuran.
Perubahan sering kali tidak terhindarkan, sehingga bertopik biasanya diperlukan.
Stub selalu dapat mengembalikan nilai yang sama, misalnya:
Tes pelanggan dapat mengandalkan nilai-nilai ini. Dalam contoh ini, perilaku konstan mungkin cukup. Untuk pengujian lain, respons rintisan khusus lebih disukai.
Atau, potongan layanan diskon hanya dapat mengembalikan jumlah yang sama, terlepas dari input.
Bagaimana rintisan ini dapat masuk ke dalam skenario yang lebih luas? Pertimbangkan perilaku sistem untuk pesanan, yang mencakup diskon dan pajak. Pajak dihitung oleh layanan mikro, mirip dengan diskon.
Ada pembeli.
Diskon yang bisa disesuaikan.
Pajak itu ditetapkan.
Ketika seorang pelanggan melakukan pemesanan:
Kemudian opsi pemesanan.
Layanan dengan negara
Jika layanan diskon menggunakan database untuk mendapatkan informasi untuk menghitung diskon, maka isinya adalah kondisi layanan. Perubahan status dalam menanggapi pembaruan data harus didokumentasikan. Misalkan layanan memiliki keadaan ini.
Dalam hal ini, layanan harus memungkinkan pengubahan data ini. Pembaruan dapat diatur sehingga setiap elemen diperbarui atau seluruh tabel diperbarui segera. Berikut adalah contoh tes perilaku untuk pembaruan individu.
Diberikan data saat ini.
Ketika suatu item diperbarui.
Kemudian data diperbarui.
Anda juga dapat memverifikasi bahwa data yang diperbarui digunakan untuk menghitung diskon.
Layanan diskon mungkin memiliki penyimpanan lokal untuk menyimpan data dalam contoh ini, tetapi mungkin juga bergantung pada layanan penyimpanan terpisah untuk data ini. Jika demikian, maka pengujian dari bagian sebelumnya berlaku untuk layanan terpisah. Tetapi setiap kecanduan menambah masalah. Apa yang seharusnya menjadi perilaku layanan jika dependensinya tidak tersedia? Untuk layanan diskon, apakah ini mengindikasikan kegagalan atau haruskah hanya mengembalikan nilai default, 0 yang sama? Terkadang Anda dapat menggunakan kebijakan penanganan kesalahan global, tetapi
seringkali keputusan tergantung pada konteks layanan .
Formulasi dan Otomatisasi Tes
Setelah perilaku layanan mikro konsisten, itu dapat dirumuskan sebagai tes otomatis. Ada beberapa sistem pengujian microservice, seperti PACT atau Karate. Selain itu, Anda dapat menggunakan kerangka kerja BDD seperti Mentimun atau FIT.
Misalnya, Mentimun menggunakan perpustakaan untuk meminta layanan. Maka informasi tambahan tentang lingkungan dapat disajikan sebagai bagian dari naskah.
Misalnya, file objek Ketimun mungkin termasuk.
Opsi langkah tergantung pada konvensi pengujian Anda.
Nilai dalam dua kolom pertama dapat ditransfer ke konvensi pemanggilan, misalnya, ke parameter kueri. Hasil dalam body harus cocok dengan kolom ketiga. Jika nama dan nilai kueri adalah nama dan nilai kolom, ini mengurangi perbedaan antara tes dan implementasi.
Untuk digunakan kembali, langkah-langkah dapat ditulis untuk layanan sewenang-wenang yang melakukan perhitungan atau menentukan hasil dari aturan bisnis. Dalam contoh di atas, menggunakan Simbol "?", Seperti pada "Jumlah Diskon" di atas, membantu penganalisa membedakan antara input dan output.
Tes juga harus mencakup kegagalan, misalnya.
Kesimpulan
Layanan Microsoft bergantung pada layanan dan sistem lain, yang membutuhkan spesifikasi antarmuka yang jelas dan pengujian yang akurat. Ini dapat dicapai dengan menggambarkan perilaku dan antarmuka yang ditentukan oleh tes. Menggunakan BDD, fungsionalitas layanan dijelaskan oleh tes yang dapat dieksekusi yang berfokus
pada semantik operasi, daripada sintaksis . Otomatisasi tes semacam itu biasanya membutuhkan pengaturan bertopik layanan lain, perilaku yang dijelaskan oleh tes BDD masing-masing.
Desain berorientasi antarmuka - IOD, mencakup kewajiban tambahan layanan: pembatasan penggunaan sumber daya, bandwidth, dan pelaporan kesalahan. Bersama-sama, BDD dan IOD membantu menggambarkan perilaku layanan sehingga pelanggan dapat dengan mudah memahami dan mengandalkannya.
- BDD untuk layanan-layanan mikro berfokus pada kerja sama triad - pengembang layanan, pengembang klien, dan penguji.
- Buat konvensi yang jelas untuk antarmuka microservice menggunakan IOD.
- Layanan microser biasanya memerlukan colokan uji untuk mempercepat pengujian.
- Tes harus independen.
- Uji skenario negatif dalam tes.
Pada 27-28 Mei, selama festival RIT ++ , di konferensi QualityConf, Artyom Malyshev akan berbicara tentang pentingnya mengekspresikan model domain dengan jelas dalam kode dan menunjukkan bagaimana melakukan ini menggunakan contoh.
Ayo bicara tentang pengembangan produk berkualitas dan bagikan ide-ide Anda!