BDD: apa itu, skenario perilaku dan framework

Apa itu BDD?

Behavior-Driven Development — adalah evolusi TDD, yang diusulkan oleh Dan North pada tahun 2006 sebagai jawaban atas masalah perumusan tes. Dalam TDD, pengembang menulis tes, tetapi pertanyaan „apa yang tepat untuk diuji?“ tetap terbuka. BDD memecahkan masalah ini dengan mengalihkan fokus dari pengujian kode ke deskripsi perilaku sistem dari sudut pandang pengguna.

Inovasi utama BDD — bahasa bersama untuk semua peserta proyek. Pengembang, tester, analis, dan klien mendiskusikan skenario dalam bahasa yang seragam, yang sekaligus merupakan tes yang dapat dijalankan. Ini menghilangkan masalah klasik „telepon rusak“, ketika kebutuhan kehilangan makna saat diteruskan dari analis ke pengembang.

Sejarah munculnya BDD

Dan North merumuskan BDD pada tahun 2006 dalam artikel „Introducing BDD“ di blog ThinkCode. Dia memperhatikan bahwa nama tes dalam TDD sering dirumuskan dalam istilah implementasi („testAddUser“), bukan dalam istilah perilaku („user should be able to register with email“). BDD mengganti kata „test“ dengan „should“ dan „assert“ dengan „expect“, menggeser fokus pada nilai bagi pengguna.

BDD sebagai praktik komunikasi

Menurut penelitian Cambridge University (2021), proyek yang menggunakan skenario BDD dalam komunikasi dengan klien mengurangi jumlah kesalahan dalam kebutuhan sebesar 35% dibandingkan dengan spesifikasi tradisional dalam dokumen teks. Skenario yang dapat dijalankan tidak memungkinkan formulasi ambigu — setiap Given-When-Then entah dijalankan atau tidak.

Bahasa Gherkin dan sintaksis

Gherkin — adalah bahasa khusus domain, yang digunakan oleh framework Cucumber dan SpecFlow untuk mendeskripsikan skenario perilaku. Gherkin menggunakan indentasi dan kata kunci untuk menstrukturkan skenario, sambil tetap dapat dibaca oleh orang tanpa latar belakang teknis.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Kata kunci Gherkin

Gherkin mendefinisikan beberapa kata kunci dasar. Feature mendeskripsikan fungsionalitas, Scenario — skenario konkret, Given — prasyarat, When — tindakan, Then — hasil yang diharapkan. Selain itu And dan But digunakan untuk menggabungkan beberapa kondisi.

Struktur file .feature

File Gherkin memiliki ekstensi .feature dan disimpan di direktori src/test/resources/features/ dalam proyek Android. Setiap file dimulai dengan deskripsi Feature, diikuti oleh satu atau lebih Scenario. Untuk parameterisasi digunakan Scenario Outline dengan tabel Examples — ini memungkinkan menjalankan skenario yang sama dengan data berbeda.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Format Given-When-Then

Given-When-Then — adalah pola struktural untuk mendeskripsikan skenario, yang diadopsi BDD dari domain-driven design. Setiap skenario terdiri dari tiga bagian: prasyarat, tindakan, dan hasil yang diharapkan. Format ini secara alami sesuai dengan Arrange-Act-Assert dari pengujian unit, tetapi menggunakan bahasa yang dapat dipahami bisnis.

Given: konteks

Blok Given mendeskripsikan keadaan sistem sebelum dimulainya skenario: data apa yang ada, komponen apa yang aktif, dalam mode apa aplikasi beroperasi. Dalam konteks mobile, ini bisa berupa „pengguna telah masuk“, „keranjang tidak kosong“ atau „perangkat dalam mode offline“.

When: tindakan

Blok When mendeskripsikan peristiwa yang diprakarsai oleh pengguna atau sistem: menekan tombol, menerima notifikasi push, respons server. Dalam aplikasi mobile, ini sering sesuai dengan pemanggilan metode ViewModel atau mengetuk elemen UI.

Then: hasil

Blok Then mendeskripsikan perubahan keadaan yang diharapkan: perubahan layar, pemanggilan API, pembaruan basis data. Pemeriksaan dalam Then harus terukur dan tidak ambigu — mereka menjadi asersi dalam kode yang dapat dijalankan.

BDD dan TDD: perbandingan pendekatan

BDD dan TDD sering membingungkan, meskipun ini adalah tingkat disiplin yang berbeda. TDD — teknik desain di tingkat kode: „bagaimana menulis implementasi“. BDD — teknik spesifikasi di tingkat kebutuhan: „apa yang harus dilakukan sistem“.

Saling melengkapi dalam proyek

Proyek mobile terbaik menggunakan TDD di tingkat kelas individu (lapisan domain) dan BDD di tingkat skenario (lapisan fitur). Ini memberikan cakupan ganda: TDD menjamin kebenaran implementasi, BDD — kebenaran pemahaman kebutuhan. Google dalam praktik internalnya menggunakan kombinasi TDD dan BDD untuk aplikasi Android, seperti yang ditunjukkan dalam dokumentasi Android Testing (2024).

Alat BDD untuk pengembangan mobile

Ekosistem BDD mencakup framework untuk semua platform dan bahasa pengembangan mobile yang populer. Pemilihan alat tergantung pada tumpukan teknologi dan tingkat otomatisasi.

Cucumber untuk Android

Cucumber — framework BDD paling populer yang bekerja dengan skenario Gherkin. Untuk proyek Android digunakan pustaka io.cucumber:cucumber-android, yang terintegrasi dengan alat pengujian UI Espresso dan Compose Test. Cucumber mendukung Kotlin dan Java, menjadikannya pilihan universal untuk studio yang menggunakan kedua bahasa.

SpecFlow untuk Xamarin

SpecFlow — framework BDD untuk ekosistem .NET, digunakan dalam proyek Xamarin.Forms dan .NET MAUI. SpecFlow terintegrasi dengan NUnit dan xUnit, dan langkah-langkahnya (step definitions) ditulis dalam C#. Untuk proyek mobile, SpecFlow memungkinkan penggunaan kembali skenario antara versi Android dan iOS aplikasi pada basis kode yang sama.

Quick/Nimble untuk iOS

Untuk pengembangan iOS dalam Swift, ada framework BDD Quick dan Nimble. Quick menyediakan DSL untuk mendeskripsikan skenario dalam gaya describe/it, dan Nimble — matcher dengan sintaksis yang dapat dibaca. Meskipun framework ini tidak menggunakan Gherkin secara langsung, mereka mengimplementasikan prinsip BDD: deskripsi perilaku dalam bahasa yang dapat dipahami seluruh tim.

Contoh skenario BDD dan kode

Mari kita lihat contoh lengkap BDD dalam proyek Android: skenario pemesanan. Pertama kita menulis skenario Gherkin, kemudian — step definitions dalam Kotlin.

Prinsip kerja BDD: three amigos

Metodologi BDD didasarkan pada pertemuan three amigos — tiga peran: pengembang, tester, dan analis. Mereka bersama-sama menulis skenario sebelum pengembangan dimulai, menetapkan pemahaman bersama tentang kebutuhan. Jika skenario tidak sesuai untuk salah satu dari tiga peserta — berarti kebutuhan dirumuskan secara ambigu. Praktik ini dijelaskan dalam buku „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) dan merupakan bagian wajib dari proses BDD dalam tim yang matang.

Skenario Gherkin pemesanan

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions dalam Kotlin

Step definitions — kode yang menghubungkan skenario Gherkin dengan implementasi tes. Setiap langkah adalah metode dengan anotasi yang sesuai dengan kata kunci Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Integrasi dengan Cucumber Android

Untuk menjalankan tes BDD dalam proyek Android digunakan CucumberAndroidJUnitRunner. Runner ini memindai file .feature di sumber daya, menemukan step definitions yang sesuai melalui ekspresi reguler, dan menjalankan skenario sebagai tes instrumental biasa. Hasilnya diformat dalam laporan HTML yang dapat dipahami klien.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Tantangan penerapan BDD dalam proyek mobile

Penerapan BDD dalam pengembangan mobile disertai dengan sejumlah kesulitan praktis. Kesadaran akan masalah ini membantu tim menghindari kekecewaan dan membangun proses BDD yang berkelanjutan.

Pemeliharaan file .feature

Masalah utama — desinkronisasi antara skenario Gherkin dan kode produksi. Jika pengembang mengubah API tanpa memperbarui step definitions, file .feature tidak lagi sesuai dengan implementasi. Solusinya — menjalankan tes BDD dalam pipeline CI/CD dan mensyaratkan status hijau untuk merge request. Praktik „BDD as a gating mechanism“ dijelaskan dalam dokumentasi Cucumber (2024) dan merupakan standar di industri.

Kinerja tes BDD

Skenario BDD di Cucumber dijalankan melalui tes instrumental pada perangkat Android atau emulator. Ini 10–50 kali lebih lambat dari tes unit biasa di JVM. Satu pengujian penerimaan dapat memakan waktu 20–30 menit untuk aplikasi Android besar. Disarankan untuk memisahkan tes BDD ke dalam job CI terpisah dan menjalankannya di malam hari, sementara tes unit — pada setiap push. Strategi semacam itu menyeimbangkan kecepatan umpan balik dan cakupan skenario.

Pelatihan tim dalam Gherkin

Transisi ke BDD memerlukan pelatihan tidak hanya pengembang, tetapi juga analis dan tester. Gherkin adalah bahasa sederhana, tetapi menulis skenario yang baik memerlukan praktik. Kesalahan umum pemula: skenario terlalu panjang (lebih dari 10 langkah), mencampuradukkan Given-When-Then, menggunakan istilah teknis dalam skenario bisnis. Menurut BDD Academy (2024), tim membutuhkan rata-rata 4–6 sprint untuk mencapai kematangan dalam menulis skenario BDD.