𝟯 𝗧𝗵𝗶𝗻𝗴𝘀 𝗡𝗼𝗯𝗼𝗱𝘆 𝗧𝗲𝗹𝗹𝘀 𝗬𝗼𝘂 𝗔𝗯𝗼𝘂𝘁 𝗕𝗗𝗗

Your Cucumber suite takes forty minutes to run. You cannot explain what a single feature file tests without reading layers of code.

Many teams adopt BDD because business stakeholders need to read tests. Then, those stakeholders stop reading. You end up with a maintenance nightmare.

Here are three truths about BDD.

𝟭. 𝗚𝗵𝗲𝗿𝗸𝗶𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲

Stop writing test scripts in Gherkin. If your scenarios list every click and every field, you are doing it wrong.

Bad Gherkin:

  • Given the user enters email "test@example.com"
  • And the user enters password "Password123!"
  • And the user clicks "Place Order"

Good Gherkin:

  • Given the user has items ready to purchase
  • When the user pays with a valid credit card
  • Then the order is confirmed

The "how" lives in your step definitions. The "what" lives in your feature files. Keep your feature files simple so a product manager can read them in seconds.

𝟮. 𝗦𝘁𝗲𝗽 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗮 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗴𝗿𝗮𝗽𝗵

Do not make step definitions import other step definitions. This creates a tangled web. If one step fails, it poisons the entire state.

The fix is simple:

  • Separate your page objects from your step definitions.
  • Use a shared domain layer.
  • Step definitions should be thin wrappers that call domain objects.

This makes your steps stateless. You can change one part of your code without breaking every other scenario.

𝟯. 𝗕𝗗𝗗 𝗶𝘀 𝗮 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁

BDD is about communication, not just testing. The tests are a side effect.

If you optimize only for test coverage or execution speed, you lose the main goal. Your feature files should be the first thing a new engineer reads to understand your system.

If a person cannot understand your system by reading your feature files, your BDD suite has failed.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄:

  • Pick your worst feature file.
  • Rewrite scenarios to be three to five lines long.
  • Move data into step definitions or factories.
  • Replace step-to-step imports with domain objects.

Can you explain your system to a new hire using only your feature files in five minutes? If not, start rewriting.

3 hal yang tidak dikatakan siapa pun tentang BDD sebelum suite Cucumber Anda menjadi mimpi buruk pemeliharaan

Behavior-Driven Development (BDD) sering dipromosikan sebagai solusi ajaib untuk menjembatani kesenjangan komunikasi antara tim teknis dan pemangku kepentingan bisnis. Namun, jika tidak dilakukan dengan benar, BDD dapat dengan cepat berubah dari alat kolaborasi yang berharga menjadi beban pemeliharaan yang sangat berat.

Berikut adalah tiga hal yang jarang dibahas saat Anda mulai mengadopsi BDD, tetapi akan sangat terasa saat suite Cucumber Anda mulai membengkak.

1. Menulis Gherkin itu sulit (dan banyak orang melakukannya dengan salah)

Banyak orang berpikir bahwa menulis Gherkin itu mudah karena "hanya menggunakan bahasa manusia". Masalahnya bukan pada kemudahannya, melainkan pada kualitasnya.

Kesalahan paling umum adalah menulis Gherkin yang terlalu teknis atau terlalu mendetail tentang bagaimana sesuatu dilakukan, alih-alih apa yang sedang dilakukan. Jika skenario Anda terlihat seperti ini:

When I click the "#submit-button" element and wait for 2 seconds and then check the database table "users"

...maka Anda tidak sedang melakukan BDD; Anda sedang menulis skrip pengujian UI yang dibungkus dalam sintaks Gherkin.

Mengapa ini masalah? Skenario yang terlalu teknis sangat rapuh. Jika pengembang mengubah ID tombol atau struktur database, skenario Anda akan gagal, meskipun fitur bisnisnya masih berfungsi dengan baik. Gherkin yang baik harus berfokus pada perilaku bisnis, bukan detail implementasi.

2. Beban pemeliharaan tumbuh secara eksponensial

Saat suite pengujian Anda tumbuh, kompleksitasnya tidak tumbuh secara linear, melainkan eksponensial. Setiap skenario baru berarti:

  • Lebih banyak step definitions yang harus dikelola.
  • Lebih banyak potensi konflik antar langkah (steps).
  • Waktu eksekusi yang lebih lama.

Jika Anda tidak memiliki strategi untuk menjaga skenario tetap ringkas dan menggunakan kembali (reuse) langkah-langkah yang ada, Anda akan terjebak dalam siklus di mana Anda menghabiskan lebih banyak waktu untuk memperbaiki pengujian yang rusak daripada mengembangkan fitur baru. Suite yang besar dan tidak terorganisir akan membuat tim merasa takut untuk melakukan perubahan pada kode karena takut merusak pengujian.

3. BDD bukan tentang pengujian otomatis; ini tentang komunikasi

Ini adalah poin yang paling sering diabaikan. Banyak tim mengadopsi BDD hanya untuk mendapatkan pengujian otomatis yang "terlihat keren", tanpa benar-benar melibatkan pemangku kepentingan bisnis dalam prosesnya.

Jika tim pengembang, QA, dan Product Owner (PO) tidak duduk bersama untuk mendiskusikan skenario sebelum pengkodean dimulai, maka Anda tidak sedang melakukan BDD. Anda hanya melakukan pengujian otomatis dengan lapisan abstraksi tambahan yang tidak perlu.

BDD yang sebenarnya adalah tentang menyepakati pemahaman yang sama tentang perilaku sistem sebelum satu baris kode pun ditulis. Tanpa kolaborasi ini, Gherkin hanyalah dokumentasi yang mahal dan sulit dipelihara.

Kesimpulan

BDD dapat menjadi alat yang sangat kuat jika digunakan untuk meningkatkan kolaborasi dan menciptakan dokumentasi yang hidup. Namun, tanpa disiplin dalam menulis Gherkin yang berfokus pada bisnis, strategi pemeliharaan yang matang, dan komitmen terhadap komunikasi antar tim, suite Cucumber Anda hanya akan menjadi beban teknis yang menghambat kecepatan tim Anda.