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

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 perkara yang tiada siapa beritahu anda tentang BDD sebelum suite Cucumber anda menjadi mimpi ngeri penyelenggaraan

BDD (Behavior-Driven Development) sering dianggap sebagai "peluru perak" untuk meningkatkan kolaborasi antara pasukan perniagaan dan pasukan teknikal. Namun, realitinya boleh menjadi sangat berbeza. Tanpa strategi yang betul, suite Cucumber anda boleh berubah daripada alat yang membantu kepada beban penyelenggaraan yang sangat besar.

Berikut adalah 3 perkara yang jarang dibincangkan tetapi sangat kritikal:

1. Perangkap Gherkin: Menulis "Bagaimana", Bukan "Apa"

Kesalahan paling biasa yang dilakukan dalam BDD adalah menulis senario Gherkin yang terlalu teknikal. Gherkin direka untuk menjadi bahasa yang boleh difahami oleh semua orang (Ubiquitous Language).

Salah (Terlalu teknikal): Given saya memasukkan "admin" dalam medan input #username And saya memasukkan "password123" dalam medan input #password When saya klik pada butang .btn-login

Betul (Fokus kepada tingkah laku): Given saya telah log masuk sebagai pentadbir

Apabila anda memasukkan butiran pelaksanaan (implementation details) ke dalam Gherkin, setiap kali UI anda berubah, senario anda akan pecah. Ini menjadikan suite anda sangat rapuh (brittle).

2. Lambakan Step Definition (Step Definition Explosion)

Apabila suite anda berkembang, anda akan mula menyedari bahawa anda mempunyai beratus-ratus Step Definition yang hampir serupa. Ini biasanya berlaku kerana kekurangan abstraksi.

Jika anda menulis langkah (steps) yang sangat spesifik untuk setiap senario, anda akan berakhir dengan kod yang berulang-ulang. Penyelenggaraan menjadi sukar kerana satu perubahan kecil dalam aplikasi memerlukan anda mengemas kini berpuluh-puluh langkah yang berbeza.

Tip: Gunakan corak parameterization dan bina langkah yang lebih generik serta boleh diguna semula.

3. Menganggap Pengujian Automatik sebagai Matlamat Utama

Ini adalah kesilapan mentaliti yang paling besar. BDD bukan sekadar tentang menjalankan ujian automatik menggunakan Cucumber. Matlamat sebenar BDD adalah komunikasi.

Jika pasukan anda hanya menulis senario Gherkin untuk memenuhi keperluan "automasi", anda telah terlepas intipati BDD. Senario tersebut sepatutnya menjadi dokumentasi hidup yang menjelaskan mengapa sesuatu ciri itu wujud dan bagaimana ia harus berkelakuan dari perspektif pengguna.

Jika senario anda tidak membantu perbincangan antara Product Owner dan pembangun, anda sebenarnya tidak melakukan BDD—anda hanya melakukan pengujian automatik yang mahal dan sukar diselenggara.

Kesimpulan

BDD boleh menjadi sangat berkuasa jika digunakan untuk memacu pemahaman bersama. Namun, jika anda membiarkan Gherkin menjadi terlalu teknikal, membiarkan Step Definition membengkak, dan melupakan aspek komunikasi, suite Cucumber anda akan menjadi mimpi ngeri penyelenggaraan.