ビヘイビア駆動開発（BDD）

ビヘイビア駆動開発（BDD）は、コードを書く前に共通理解を築くための手法です。プロダクト、開発、テスト（「スリーアミーゴス」と呼ばれることが多い）が、機能がどう振る舞うべきかを具体例を使って話し合います。その具体例が受け入れ基準となり、多くのチームは Cucumber、SpecFlow の後継である Reqnroll、Behave などのツールを使って、実行可能な仕様として自動化します。

具体例

割引ルールについての会話は、次のような具体例になります。

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

価値があるのは 2 つ目のシナリオです。これを書くことで、誰かが間違ったものを作る前に「100 を超える場合なのか、100 以上なのか」という問いが必ず出てきます。

3 つのプラクティス

1. ディスカバリー（発見）。 具体例を使って機能を探り、エッジケースや未解決の疑問を見つけます。
2. フォーミュレーション（定式化）。 合意した具体例を、ビジネス側も読める構造化された形式（通常は Gherkin）で書きます。
3. オートメーション（自動化）。 各ステップをコードに結び付け、具体例をテストとして実行できるようにし、生きたドキュメントとして機能させます。

よくある間違い

• BDD をテストツールとして扱う。 会話なしに、コードを書いた後で 1 人で Gherkin を書いても、共通理解というメリットはなく、翻訳レイヤーのコストだけが残ります。
• UI レベルのステップ。 「id が submit のボタンをクリックする」は振る舞いではなくインターフェースを記述しています。ステップは画面のデザインが変わっても通用するべきです。
• すべてのシナリオをブラウザ経由で自動化する。 上記の割引のようなビジネスルールは、通常 API やサービス層に対して自動化した方が速く、安定します。
• 巨大なステップライブラリ。 微妙に異なる何百ものステップ定義は保守が困難です。語彙は小さく、ドメインに沿ったものに保ちます。

BDD がうまく機能するのは、ビジネス側の人が実際にシナリオを読み、内容に関わる場合です。エンジニア以外が誰も見ないのであれば、適切な名前を付けた普通のテストコードの方がシンプルなことがよくあります。