Behavior-Driven Development (BDD): Membangun Aplikasi yang Sesuai Kebutuhan Bisnis dan Mudah Diuji

1. Pendahuluan

Pernahkah Anda mengerjakan sebuah fitur, menghabiskan waktu berjam-jam untuk coding dan testing, hanya untuk menyadari bahwa hasil akhirnya tidak sesuai dengan apa yang dibayangkan oleh tim produk atau klien? Frustrasi, kan? Ini adalah masalah umum dalam pengembangan perangkat lunak, seringkali disebabkan oleh kesenjangan komunikasi antara stakeholder teknis dan non-teknis.

Di sinilah Behavior-Driven Development (BDD) hadir sebagai jembatan. BDD bukan sekadar teknik testing; ini adalah metodologi pengembangan perangkat lunak yang mendorong kolaborasi erat antara developer, QA, dan stakeholder bisnis. Tujuannya? Memastikan semua orang memiliki pemahaman yang sama tentang bagaimana sebuah fitur seharusnya berperilaku dari sudut pandang pengguna, sebelum kode ditulis.

BDD membantu kita menjawab pertanyaan krusial: “Apa yang seharusnya dilakukan aplikasi ini?” dan “Bagaimana kita tahu bahwa aplikasi ini melakukan hal yang benar?”. Dengan fokus pada perilaku yang diharapkan, BDD tidak hanya meningkatkan kualitas kode tetapi juga memastikan produk yang kita bangun benar-benar memenuhi kebutuhan bisnis. Mari kita selami lebih dalam!

2. Mengapa BDD Penting untuk Developer?

Sebagai developer, kita seringkali terjebak dalam detail teknis: algoritma, arsitektur, atau optimasi performa. Namun, inti dari pekerjaan kita adalah membangun sesuatu yang bernilai bagi pengguna dan bisnis. BDD membantu kita menjaga fokus pada nilai tersebut.

✅ Mengurangi Ambiguatas dan Salah Tafsir

Bayangkan Anda sedang membangun sebuah fitur “Keranjang Belanja”. Tanpa BDD, deskripsi fitur mungkin hanya “Pengguna bisa menambahkan produk ke keranjang.” Ini bisa ditafsirkan macam-macam:

Bagaimana jika produk sudah ada di keranjang? Ditambahkan lagi, atau jumlahnya bertambah?
Apa yang terjadi jika keranjang kosong dan pengguna mencoba checkout?
Apakah ada batas jumlah produk yang bisa ditambahkan?

Dengan BDD, skenario ini akan didiskusikan dan didokumentasikan secara eksplisit dalam bahasa yang mudah dimengerti semua pihak.

🎯 Meningkatkan Kolaborasi Tim

BDD mendorong konsep “Three Amigos”: kolaborasi antara Product Owner (Bisnis), QA (Penguji), dan Developer. Mereka duduk bersama untuk mendefinisikan behavior dari sebuah fitur. Ini bukan cuma meeting, tapi sesi diskusi mendalam yang menghasilkan pemahaman bersama dan mengurangi asumsi.

💡 “Living Documentation” yang Selalu Up-to-Date

Skenario BDD yang ditulis dalam format spesifik (seperti Gherkin, yang akan kita bahas nanti) berfungsi ganda sebagai dokumentasi dan test case otomatis. Saat kode berubah, test BDD akan gagal jika perilaku yang diharapkan ikut berubah. Ini berarti dokumentasi Anda selalu “hidup” dan mencerminkan keadaan aplikasi saat ini.

⚙️ Kode Lebih Mudah Diuji dan Dirawat

Karena BDD mendorong kita untuk berpikir tentang perilaku sebelum menulis kode, kita cenderung merancang kode yang lebih modular, dengan tanggung jawab yang jelas, dan lebih mudah diuji. Test BDD yang otomatis juga menjadi safety net yang kuat saat melakukan refactoring atau menambahkan fitur baru.

Pada dasarnya, BDD membantu kita membangun produk yang tepat, dengan cara yang tepat.

3. Prinsip Inti BDD: Kolaborasi, Contoh, dan Otomatisasi

BDD berputar pada beberapa pilar utama:

🤝 Kolaborasi (“Three Amigos”)

Ini adalah jantung BDD. Product Owner, QA, dan Developer bertemu untuk membahas dan mendefinisikan persyaratan fitur. Diskusi ini berfokus pada:

Apa yang ingin dicapai oleh fitur ini? (Tujuan bisnis)
Siapa yang akan menggunakan fitur ini? (Pengguna)
Bagaimana fitur ini akan berperilaku dalam berbagai skenario? (Contoh konkret)

Dari diskusi ini, muncullah skenario-skenario perilaku yang akan menjadi dasar pengembangan.

📝 Contoh Konkret (Skenario)

Daripada menulis spesifikasi yang abstrak, BDD menggunakan contoh konkret untuk mendefinisikan perilaku. Contoh-contoh ini ditulis dalam format yang terstruktur dan mudah dibaca, biasanya menggunakan sintaks Gherkin: Given-When-Then.

Misalnya, untuk fitur “Login Pengguna”:

Skenario: Login Berhasil Given pengguna berada di halaman login When pengguna memasukkan username “user@example.com” dan password “password123” And pengguna menekan tombol “Login” Then pengguna diarahkan ke halaman dashboard And menampilkan pesan “Selamat datang, user!”

Contoh ini jelas, tidak ambigu, dan bisa dimengerti oleh siapa saja, terlepas dari latar belakang teknisnya.

🤖 Otomatisasi (Executable Specifications)

Skenario yang ditulis dalam Gherkin kemudian diotomatisasi menjadi test. Ini berarti setiap Given, When, dan Then akan dipetakan ke kode pengujian yang sebenarnya. Saat test ini dijalankan, mereka memverifikasi bahwa aplikasi berperilaku persis seperti yang disepakati. Jika test lulus, kita tahu aplikasi bekerja sesuai harapan. Jika gagal, kita tahu ada kesenjangan antara implementasi dan ekspektasi.

📌 Penting: Urutan BDD adalah:

Diskusi (Three Amigos)
Definisi Skenario (Gherkin)
Otomatisasi Test (Kode)
Implementasi Fitur (Kode Produksi)
Refactor Test dan Kode

Ini berbeda dengan TDD (Test-Driven Development) yang fokus pada menulis unit test sebelum kode produksi. BDD lebih tinggi levelnya, berfokus pada perilaku sistem secara keseluruhan.

4. Memahami Gherkin: Bahasa Komunikasi BDD

Gherkin adalah bahasa domain-specific (DSL) yang digunakan untuk mendeskripsikan perilaku perangkat lunak tanpa detail implementasi. Ini dirancang agar mudah dibaca oleh non-developer dan cukup terstruktur untuk diotomatisasi.

Struktur dasar Gherkin adalah:

Feature: Judul Fitur
  Sebagai [peran]
  Saya ingin [kapabilitas]
  Agar [manfaat]

  Scenario: Judul Skenario
    Given [konteks awal]
    When [aksi yang dilakukan]
    Then [hasil yang diharapkan]
    And [kondisi tambahan]
    But [kondisi pengecualian]

  Scenario Outline: Judul Skenario dengan Variabel
    Given [konteks awal <data1>]
    When [aksi yang dilakukan <data2>]
    Then [hasil yang diharapkan <data3>]

    Examples:
      | data1 | data2 | data3 |
      | nilai1 | nilai2 | nilai3 |
      | nilai4 | nilai5 | nilai6 |

Contoh Skenario Gherkin: Fitur Penarikan Dana

Mari kita lihat contoh yang lebih kompleks untuk fitur penarikan dana dari rekening bank:

Feature: Penarikan Dana dari Rekening Bank
  Sebagai pelanggan bank
  Saya ingin dapat menarik uang tunai dari ATM
  Agar saya bisa mendapatkan uang saat saya membutuhkannya

  Scenario: Penarikan dana berhasil dengan saldo cukup
    Given saya memiliki saldo Rp 1.000.000 di rekening
    And kartu ATM saya valid
    When saya menarik dana sebesar Rp 500.000
    Then saldo rekening saya menjadi Rp 500.000
    And mesin ATM mengeluarkan uang tunai Rp 500.000

  Scenario: Penarikan dana gagal karena saldo tidak cukup
    Given saya memiliki saldo Rp 200.000 di rekening
    And kartu ATM saya valid
    When saya menarik dana sebesar Rp 500.000
    Then saldo rekening saya tetap Rp 200.000
    And mesin ATM menampilkan pesan "Saldo tidak mencukupi"

  Scenario Outline: Penarikan dana dengan nominal yang berbeda
    Given saya memiliki saldo Rp <saldo_awal> di rekening
    And kartu ATM saya valid
    When saya menarik dana sebesar Rp <nominal_tarik>
    Then saldo rekening saya menjadi Rp <saldo_akhir>
    And mesin ATM menampilkan pesan "<pesan>"

    Examples:
      | saldo_awal | nominal_tarik | saldo_akhir | pesan                  |
      | 1000000    | 100000        | 900000      | "Penarikan berhasil"   |
      | 500000     | 250000        | 250000      | "Penarikan berhasil"   |
      | 100000     | 200000        | 100000      | "Saldo tidak mencukupi"|

Setiap baris Given, When, Then adalah “step”. Tools BDD akan mencari implementasi kode untuk setiap step ini.

5. Implementasi BDD dalam Praktik: Tools dan Contoh Kode

Untuk mengotomatisasi skenario Gherkin, kita memerlukan framework BDD yang bisa menerjemahkan teks Gherkin menjadi kode yang dapat dieksekusi. Beberapa tools populer:

JavaScript/TypeScript: Cucumber.js, Jest-Cucumber
Java: Cucumber-JVM
Python: Behave, Cucumber-Python
.NET: SpecFlow
Ruby: Cucumber

Mari kita lihat contoh sederhana menggunakan Jest-Cucumber untuk aplikasi React/JavaScript.

Pertama, instal dependensi yang diperlukan:

npm install --save-dev jest-cucumber @testing-library/react @testing-library/jest-dom

Membuat File Gherkin (`.feature`)

Buat file Login.feature:

# features/Login.feature
Feature: Login Pengguna
  Sebagai pengguna terdaftar
  Saya ingin bisa login ke akun saya
  Agar saya bisa mengakses fitur-fitur pribadi

  Scenario: Login berhasil dengan kredensial yang benar
    Given saya berada di halaman login
    When saya memasukkan username "admin@example.com" dan password "password123"
    And saya menekan tombol "Login"
    Then saya seharusnya melihat halaman dashboard
    And saya seharusnya melihat pesan "Selamat datang, Admin!"

  Scenario: Login gagal dengan kredensial yang salah
    Given saya berada di halaman login
    When saya memasukkan username "admin@example.com" dan password "salahpassword"
    And saya menekan tombol "Login"
    Then saya seharusnya melihat pesan error "Username atau password salah"
    And saya seharusnya tetap berada di halaman login

Membuat Implementasi Step (`.steps.js`)

Kemudian, buat file untuk mengimplementasikan setiap step Gherkin. Ini adalah jembatan antara teks Gherkin dan kode JavaScript/React kita.

// features/step-definitions/