Perdebatan TDD vs BDD sering kali dibingkai sebagai pemilihan pihak. Kenyataannya, mereka menjawab pertanyaan yang berbeda. Pengembangan berbasis pengujian menanyakan apakah kode tersebut sesuai dengan keinginan pengembang, sedangkan pengembangan berbasis perilaku menanyakan apakah tim menyetujui apa yang harus dilakukan perangkat lunak.

Untuk membuat perbedaan menjadi nyata, kami membuat satu fitur diskon kecil pada setiap pendekatan. Kami menjalankan kode pada Python 3.13, menggunakan pustaka standar, dan hasil di bawah berasal dari proses tersebut. Bagian BDD menggunakan pelari kecil kita sendiri untuk menunjukkan mekanismenya, sehingga proyek nyata akan menggunakan alat seperti Mentimun atau berperilaku sebagai gantinya.

Jawaban singkatnya

Pengembangan berbasis pengujian (TDD) adalah praktik pengkodean. Anda menulis tes kecil yang gagal, lulus dengan kode paling sederhana, dan kemudian memperbaiki desainnya. Pengujian ditulis dalam kode, dan sebagian besar dilakukan oleh pengembang. Kent Beck mempopulerkan praktik ini.

Pembangunan berbasis perilaku (BDD) adalah praktik kolaborasi yang tumbuh dari TDD, dan Dan North yang memperkenalkan istilah tersebut. Pengembang, penguji, dan pebisnis sepakat mengenai contoh bagaimana sistem harus berperilaku, ditulis dalam bahasa sederhana, dan contoh tersebut kemudian dapat diotomatisasi.

TDD vs BDD berdampingan

Fiturnya

Berikut aturan bisnis yang akan kami terapkan: Pesanan 1000 atau lebih mendapat diskon 10%. Anggota mendapat tambahan diskon 5% untuk pesanan tersebut.

Hal ini mungkin terdengar jelas, namun sudah menjadi hal yang ambigu. Apakah anggota yang membelanjakan 500 mendapat diskon 5%? Kalimatnya mengatakan “perintah itu”, jadi kita asumsikan tidak. Ingatlah hal itu, karena pertanyaan seperti inilah yang dirancang BDD untuk dilontarkan sejak dini.

Membangunnya dengan TDD

TDD mengikuti loop pendek yang dikenal sebagai red, green, refactor:

Ini adalah pengujian kami, dengan satu pengujian untuk setiap aturan:

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

Kami kemudian menulis kode dalam tiga tahap, menjalankan pengujian setelahnya. Sesi TDD yang ketat menambahkan satu tes pada satu waktu, dan ini menunjukkan perkembangan yang sama:

Tahap 1: hal paling sederhana

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

Mengembalikan angka nol terlihat konyol, tetapi ini membuktikan bahwa pengujian tersebut sebenarnya bisa gagal, dan satu-satunya pengujian yang dilewatinya adalah aturan “tidak ada diskon”.

Tahap 2: tambahkan ambang batas

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

Tahap 3: menambah anggota, dan membersihkan

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

Ketiganya lulus. Tapi bacalah versi ini dengan cermat. Ini memberi anggota yang membelanjakan 500 diskon 5%, yang menurut kami bukan maksud dari aturan tersebut. Tidak ada tes yang mencakup kasus itu, jadi tidak ada yang menandainya. TDD hanya melindungi perilaku yang ingin Anda uji. Itu adalah batasan nyata, dan alasan mengapa percakapan tentang contoh sangat penting.

Mengapa siklus itu penting

• Merah membuktikan bahwa tes tersebut berhasil. Tes yang tidak pernah gagal belum tentu menguji apa pun.
• Hijau membuat Anda tetap fokus. Anda hanya menulis kode yang diperlukan, yang membantu mencegah rekayasa berlebihan.
• Refactor menjaga kualitas tetap tinggi. Pengujian memberi Anda kepercayaan diri untuk mengubah desain dengan aman.
• Ini mempengaruhi desain. Kode yang sulit untuk diuji sering kali digabungkan terlalu erat, dan Anda langsung menyadarinya.

tutorial pytest kami menunjukkan cara yang lebih mudah untuk menulis pengujian seperti ini, dan analisis nilai batas menjelaskan mengapa kami memilih 999 dan 1000 sebagai nilai.

Membangunnya dengan BDD

BDD dimulai dengan percakapan, bukan dengan alat. Seringkali ini merupakan pertemuan singkat yang dikenal sebagai tiga sahabat, dengan staf produk, pengembang, dan penguji mendiskusikan contoh nyata:

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

Pertukaran yang satu itu akan menangkap masalah dalam kode TDD kami. Mereka kemudian mencatat contoh mereka dalam format terstruktur yang disebut Gherkin:

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

Siapa pun di tim dapat membacanya dan berkata “ya, itu benar” atau “tidak, itu salah”. Meskipun Anda tidak pernah mengotomatiskannya, skenario tersebut telah memberikan hasil yang bermanfaat.

Menghubungkan langkah-langkah ke kode

Alat menghubungkan setiap baris bahasa sederhana ke suatu fungsi, yang disebut definisi langkah. Untuk menunjukkan idenya, kami sendiri yang menulis versi kecilnya dan menjalankan skenario pertama:

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

Alat nyata menambahkan parameter, sehingga satu langkah dapat mencocokkan “1000” dan “500”, ditambah pelaporan. Hasilnya adalah dokumentasi langsung: deskripsi sederhana tentang sistem yang gagal total jika tidak lagi benar.

Menulis skenario yang bagus

Skenario yang menjelaskan klik dan ID bidang terputus pada setiap desain ulang, dan pembaca bisnis berhenti membacanya. Simpan detail antarmuka pengguna dalam kode langkah. Skenario ini mirip dengan contoh dalam kasus uji vs skenario pengujian, dan sering digunakan dalam pengujian penerimaan pengguna juga.

Menggunakan keduanya secara bersamaan

Keduanya secara alami cocok dengan alur kerja “luar-dalam”:

1. Tim menyetujui perilaku dan menulis skenario BDD. Gagal, karena belum ada.
2. Pengembang menggunakan TDD untuk membangun unit kecil yang dibutuhkan.
3. Pengujian unit berhasil, dan pada akhirnya skenario pun berhasil.
4. Semuanya berjalan di pipa CI/CD Anda.

Pertahankan masing-masing pada level yang tepat. Anda harus memiliki beberapa skenario untuk perilaku penting, dan banyak pengujian unit cepat untuk detailnya. Panduan kami untuk pengujian unit vs integrasi mencakup keseimbangan.

Alat

Kapan menggunakan masing-masing

TDD cocok ketika:

• Anda menulis logika yang kompleks, seperti penetapan harga, penguraian, atau izin.
• Anda sedang memperbaiki bug, karena Anda dapat mereproduksinya terlebih dahulu dengan pengujian yang gagal.
• Anda sedang mengerjakan kode yang akan sering berubah.

BDD cocok ketika:

• Aturan bisnis itu rumit, dan kesalahpahaman bisa berakibat buruk.
• Orang-orang non-teknis akan benar-benar membaca dan mendiskusikan skenarionya.
• Beberapa tim memerlukan definisi bersama tentang bagaimana sesuatu berperilaku.

Keduanya mungkin berlebihan ketika: Anda sedang menulis prototipe sekali pakai atau mengeksplorasi ide teknis yang tidak jelas. Banyak pengembang melakukan lonjakan terlebih dahulu, lalu menulis ulang dengan pengujian. Perkakas BDD juga merupakan investasi yang buruk jika tidak ada orang di luar bidang teknik yang melihat skenarionya. Dalam hal ini, tes biasa dengan nama baik lebih sederhana.

Kesalahan umum

• Memperlakukan BDD sebagai alat pengujian. Mentimun tanpa kolaborasi hanyalah cara yang panjang untuk menulis tes.
• Pengujian implementasi di TDD. Pengujian yang terkait dengan detail pribadi terhenti selama setiap refaktorisasi.
• Melewatkan langkah refactor. Anda lulus tes di atas kode yang berantakan.
• Menulis tes setelah kode dan menyebutnya TDD. Itu masih berguna, tetapi Anda kehilangan masukan desain.
• Menulis terlalu banyak skenario UI. Ini menjadi lambat dan tidak stabil. Lihat tes yang tidak stabil.
• Mengejar jumlah cakupan. Liputan yang baik masih belum memperhitungkan perilaku yang tidak dipertimbangkan oleh siapa pun, seperti yang ditunjukkan dalam contoh kami.

Penutup

TDD membantu Anda membangun sesuatu dengan benar, dan BDD membantu Anda membangun sesuatu yang benar. Contoh diskon kami menunjukkan kedua sisi: kode lulus semua pengujiannya, namun percakapan sederhana mengungkapkan asumsi yang salah. Cobalah pada fitur kecil Anda berikutnya. Tulis tiga contoh nyata dengan rekan kerja sebelum kode apa pun, lalu buatlah satu pengujian yang gagal dalam satu waktu.

Pertanyaan yang sering diajukan

Teruslah belajar