𝟯 𝗧𝗵𝗶𝗻𝗴𝘀 𝗡𝗼𝗯𝗼𝗱𝘆 𝗧𝗲𝗹𝗹𝘀 𝗬𝗼𝘂 𝗔𝗯𝗼𝘂𝘁 𝗕𝗗𝗗
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.
Cucumberスイートがメンテナンスの悪夢に変わる前に、誰も教えてくれないBDDに関する3つのこと
BDD（振る舞い駆動開発）は、素晴らしい約束を掲げて登場しました。コラボレーション、生きたドキュメント、そしてビジネス要件とコードの完全な一致。しかし、多くのチームが、数ヶ月後にはメンテナンスが不可能な、壊れやすく、実行速度の遅いCucumberテストの山に直面することになります。
なぜ、素晴らしいはずのBDDが、開発チームにとっての重荷になってしまうのでしょうか？
Cucumberスイートがメンテナンスの悪夢に変わる前に、知っておくべき3つの真実をお伝えします。
1. 振る舞いではなく、実装の詳細をテストしている
最も一般的な間違いは、Gherkinのシナリオに「どのように（How）」を書いてしまうことです。
例えば、次のようなシナリオを見てみましょう：
When I enter "user@example.com" into the email input field
And I click the blue "Submit" button
これは、ユーザーの「振る舞い」ではなく、UIの「実装の詳細」です。もし、メール入力欄がドロップダウンに変わったり、ボタンのデザインが変わったり、あるいは入力方法が変更されたりした場合、このテストは失敗します。ビジネスのロジックは変わっていないのに、テストだけが壊れてしまうのです。
解決策: Gherkinには「何を（What）」を書くべきです。
When I log in with valid credentials
これにより、UIの変更に対してテストが堅牢になり、シナリオがビジネスの意図をより明確に反映するようになります。
2. ステップ定義の墓場（Step Definition Graveyard）
2つ目の問題は、細かすぎるステップ定義です。
開発者は、再利用性を高めようとして、あまりにも細かなステップを大量に作成してしまいがちです。その結果、似たようなステップが何百個も存在し、どれを使えばいいのか分からなくなったり、同じようなステップが重複して作成されたりします。
これが「ステップ定義の墓場」です。新しいシナリオを書くたびに、既存のステップを組み合わせるのではなく、新しいステップを「とりあえず」作ってしまう。これが、メンテナンスコストを爆発させる原因です。
解決策: ステップは、ビジネスの概念に基づいた抽象度の高いものであるべきです。細かなUI操作を一つのステップにまとめ、ビジネスの文脈で意味を持つ単位で定義してください。
3. 「三人のアミーゴ（Three Amigos）」が不在である
BDDは、テスト手法ではなく、コミュニケーションのプロセスです。
もし、開発者が一人でFeatureファイルを書いているとしたら、それはBDDではありません。それは単に「少し複雑な自動テスト」をしているだけです。
BDDの真の価値は、「三人のアミーゴ（Three Amigos）」、つまり**ビジネス（プロダクトオーナー）、開発、テスト（QA）**の3者が、シナリオを検討し、共通の理解を形成することにあります。
もし、プロダクトオーナーがFeatureファイルの内容を理解していなかったり、検証していなかったりする場合、そのシナリオはビジネスの要件を正しく反映していない可能性があります。その結果、間違ったものを「正しく」テストすることになってしまいます。
まとめ
BDDは強力なツールですが、使い方を間違えると、開発スピードを著しく低下させる負債となります。
- 実装ではなく、振る舞いに焦点を当てる。
- 抽象度の高い、再利用可能なステップを設計する。
- コミュニケーションのプロセスとしてBDDを活用する。
これらを意識するだけで、あなたのCucumberスイートは、メンテナンスの悪夢から、価値を生み出す強力な資産へと変わるはずです。