Apa itu Behavior-Driven Development (BDD)
Behavior-Driven Development (BDD) adalah metodologi pengembangan perangkat lunak Agile yang menekankan pada kolaborasi, komunikasi, dan pemahaman bersama antara stakeholder yang berbeda dalam sebuah proyek. Metodologi ini diperkenalkan pada awal tahun 2000 sebagai evolusi dari Test-Driven Development (TDD). BDD bertujuan untuk menyediakan bahasa yang umum bagi pengembang, tester, dan perwakilan bisnis untuk mendefinisikan perilaku yang diharapkan dari aplikasi secara jelas, singkat, dan tidak ambigu.
Tujuan utama dari BDD adalah untuk memastikan bahwa semua anggota tim memahami persyaratan dan perilaku yang diinginkan dari aplikasi. Hal ini dilakukan dengan fokus pada cerita pengguna dan skenario, yang ditulis dalam format yang mudah dipahami oleh stakeholder yang berbeda. BDD mendorong penggunaan contoh untuk mendeskripsikan perilaku aplikasi dan mendorong proses pengembangan.
Proses BDD
Secara essensial, aktivitas BDD sehari-hari adalah proses tiga tahap yang berulang:
- Discovery
- Formulation
- Automation
Discovery: Percakapan Kolaboratif
Tahap discovery adalah titik awal proses BDD, di mana anggota tim bersama-sama mendiskusikan dan mendefinisikan perilaku yang diharapkan dari aplikasi. Tahap ini mendorong komunikasi terbuka dan kolaborasi antara pengembang, tester, dan perwakilan bisnis, memastikan bahwa semua orang memiliki pemahaman bersama tentang persyaratan proyek.
Selama discovery, tim terlibat dalam percakapan kolaboratif, sering disebut sesi "Three Amigos", di mana mereka membahas cerita pengguna dan skenario. Cerita pengguna memberikan deskripsi tingkat tinggi dari fungsionalitas yang diinginkan, sedangkan skenario memerinci contoh spesifik tentang bagaimana aplikasi harus berperilaku dalam situasi yang berbeda. Tujuan dari percakapan ini adalah untuk mengidentifikasi setiap ambiguitas atau kesalahpahaman dan mencapai konsensus tentang perilaku yang diharapkan.
Formulation: Menulis Skenario
Setelah tim memiliki pemahaman yang jelas tentang perilaku yang diharapkan, mereka beralih ke tahap formulasi, di mana mereka menulis skenario dalam format yang terstruktur dan mudah dibaca. Skenario adalah aspek penting dari BDD, karena mereka berfungsi sebagai dokumentasi dan spesifikasi yang dapat dijalankan untuk aplikasi.
Skenario ditulis menggunakan sintaks Given-When-Then, yang memberikan struktur yang jelas dan konsisten untuk mendefinisikan prasyarat, tindakan, dan hasil yang diharapkan:
- Given: Mendeskripsikan keadaan awal atau konteks dari sistem.
- When: Menentukan tindakan atau peristiwa yang terjadi.
- Then: Menjelaskan hasil atau hasil yang diharapkan.
Penggunaan sintaks ini membantu memastikan bahwa skenario mudah dipahami oleh stakeholder yang berbeda. Selain itu, skenario harus ditulis dengan fokus pada perilaku aplikasi, bukan detail implementasinya.
Automation: Mengimplementasikan Kode Uji
Tahap terakhir dari proses BDD adalah otomatisasi, di mana skenario diterjemahkan ke dalam kode uji yang dapat dijalankan untuk memverifikasi perilaku aplikasi. Tahap ini melibatkan menulis definisi langkah, yang merupakan potongan kode yang memetakan setiap langkah dalam skenario ke kode yang sesuai dalam aplikasi.
Dengan mengimplementasikan kode uji berdasarkan skenario, tim memastikan bahwa perilaku aplikasi sesuai dengan persyaratan yang disepakati. Kode uji juga berfungsi sebagai bentuk dokumentasi hidup yang tetap terkini seiring evolusi aplikasi, menyediakan representasi perilaku yang diharapkan yang jelas dan akurat pada setiap saat.
Saat aplikasi dikembangkan dan diperbarui, tes otomatis dijalankan secara terus-menerus untuk memastikan bahwa perubahan tidak merusak fungsionalitas yang ada. Proses pengujian yang terus-menerus ini membantu mengidentifikasi dan menyelesaikan masalah pada tahap awal dalam siklus pengembangan, yang pada akhirnya menghasilkan perangkat lunak berkualitas tinggi dan proses pengembangan yang lebih efisien.
Alat dan Kerangka Kerja BDD
Untuk mendukung implementasi BDD, berbagai alat dan kerangka kerja telah dikembangkan. Alat-alat ini memfasilitasi penulisan, eksekusi, dan pelaporan skenario dan uji, sehingga memudahkan tim untuk mengikuti praktik BDD.
Cucumber
Cucumber adalah salah satu kerangka kerja BDD yang paling populer, mendukung beberapa bahasa pemrograman, termasuk Ruby, Java, JavaScript, dan Python. Ini menyediakan cara sederhana untuk mendefinisikan skenario menggunakan bahasa Gherkin dan untuk mengeksekusinya sebagai tes otomatis dengan memetakan ke definisi langkah. Cucumber juga terintegrasi dengan berbagai perpustakaan pengujian dan mendukung plugin untuk memperluas fungsionalitasnya.
SpecFlow
SpecFlow adalah kerangka kerja BDD untuk pengembang .NET, yang sangat mirip dengan Cucumber. Ini memungkinkan definisi skenario menggunakan Gherkin dan pembuatan definisi langkah dalam C#. SpecFlow terintegrasi dengan perpustakaan pengujian populer seperti NUnit dan xUnit, dan dapat digunakan bersama dengan alat integrasi berkelanjutan seperti Jenkins dan TeamCity.
Behat
Behat adalah kerangka kerja BDD yang dirancang khusus untuk pengembang PHP. Ini mendukung definisi skenario dalam Gherkin dan penulisan definisi langkah dalam PHP. Behat terintegrasi dengan PHPUnit dan perpustakaan pengujian lainnya, menjadikannya pilihan populer untuk proyek PHP. Ini juga termasuk berbagai ekstensi untuk meningkatkan fungsionalitasnya.
JBehave
JBehave adalah kerangka kerja BDD untuk pengembang Java, yang dikembangkan oleh Dan North, pencipta BDD. Seperti Cucumber, ia mendukung definisi skenario menggunakan Gherkin dan penulisan definisi langkah dalam Java. JBehave terintegrasi dengan perpustakaan pengujian Java populer, seperti JUnit, dan dapat digunakan dengan alat integrasi berkelanjutan seperti Jenkins dan Bamboo.
Karate
Karate adalah kerangka kerja BDD untuk pengembang Java, yang dirancang khusus untuk pengujian API. Berbeda dengan kerangka kerja BDD lainnya, Karate mengombinasikan kemampuan mendefinisikan skenario menggunakan Gherkin dengan DSL (Domain-Specific Language) bawaan untuk menulis tes, menghilangkan kebutuhan untuk definisi langkah terpisah. Pendekatan ini menyederhanakan proses penulisan tes dan membuatnya lebih mudah diakses oleh anggota tim dengan berbagai latar belakang teknis.
Contoh BDD
Untuk mengilustrasikan proses BDD dalam praktik, mari kita telusuri contoh sederhana penerapan BDD untuk aplikasi perbankan online fiktif. Tujuan dari contoh ini adalah untuk menunjukkan bagaimana konsep dan praktik BDD diterapkan dalam skenario dunia nyata.
Cerita Pengguna
Pemilik produk menyediakan tim pengembangan dengan cerita pengguna yang menjelaskan fungsionalitas yang diinginkan:
Sebagai pelanggan bank,
Saya ingin mentransfer dana antara akun saya,
Agar saya dapat mengelola keuangan saya lebih efektif.
Discovery: Percakapan Kolaboratif
Tim pengembangan, bersama dengan pemilik produk dan seorang perwakilan jaminan kualitas, terlibat dalam sesi "Three Amigos" untuk membahas cerita pengguna dan mengidentifikasi skenario yang mewakili perilaku yang diharapkan.
Formulasi: Menulis Skenario
Tim secara kolaboratif menulis skenario berikut untuk menjelaskan perilaku yang diharapkan:
Fitur: Transfer Dana
Skenario: Mentransfer dana antara akun dengan saldo cukup
Diberikan saya memiliki rekening cek dengan saldo 500
Dan saya memiliki rekening tabungan dengan saldo 1000
Ketika saya mentransfer 200 dari rekening cek saya ke rekening tabungan saya
Kemudian saldo rekening cek saya harus menjadi 300
Dan saldo rekening tabungan saya harus menjadi 1200
Skenario: Mentransfer dana antara akun dengan saldo tidak mencukupi
Diberikan saya memiliki rekening cek dengan saldo 100
Dan saya memiliki rekening tabungan dengan saldo 1000
Ketika saya mencoba mentransfer 200 dari rekening cek saya ke rekening tabungan saya
Kemudian transfer harus ditolak
Dan saldo rekening cek saya harus tetap 100
Dan saldo rekening tabungan saya harus tetap 1000
Otomatisasi: Mengimplementasikan Kode Uji
Tim pengembangan mengimplementasikan definisi langkah untuk skenario menggunakan kerangka kerja BDD yang mereka pilih. Dalam contoh ini, kita akan menggunakan Behave dengan Python:
from behave import given, when, then
from bank_account import Account, InsufficientFundsException
@given("I have a checking account with a balance of {balance:d}")
def step_given_checking_account_balance(context, balance):
context.checking_account = Account(balance)
@given("I have a savings account with a balance of {balance:d}")
def step_given_savings_account_balance(context, balance):
context.savings_account = Account(balance)
@when("I transfer {amount:d} from my checking account to my savings account")
def step_when_transfer_from_checking_to_savings(context, amount):
context.checking_account.transfer_to(context.savings_account, amount)
@when("I attempt to transfer {amount:d} from my checking account to my savings account")
def step_when_attempt_transfer_from_checking_to_savings(context, amount):
try:
context.checking_account.transfer_to(context.savings_account, amount)
except InsufficientFundsException:
# Transfer declined
@then("my checking account balance should be {expected_balance:d}")
def step_then_checking_account_balance(context, expected_balance):
assert context.checking_account.get_balance() == expected_balance
@then("my savings account balance should be {expected_balance:d}")
def step_then_savings_account_balance(context, expected_balance):
assert context.savings_account.get_balance() == expected_balance
@then("the transfer should be declined")
def step_then_transfer_declined(context):
# Handled by the try-except block in the step definition above
Referensi
Ryusei Kakujo
Focusing on data science for mobility
Bench Press 100kg!