BDD（ビヘイビア駆動開発） とは？

TDDは「関数にこの入力を渡したらこの出力が返る」というコードレベルのテストを先に書く。BDDは「ユーザーがログインボタンを押したらダッシュボードが表示される」というユーザー目線のシナリオを先に書く。視点の高さが違うんだ。

BDDのシナリオを書くフォーマット。Given（〇〇という状態で）、When（△△をしたら）、Then（□□になる）の3行で1つの振る舞いを表現する。例えば「Given: ログイン済みのユーザーが、When: カートに商品を追加したら、Then: カートの個数が1増える」みたいに書く。

そこがBDDの狙い。企画担当やビジネス側の人がシナリオを書いて、エンジニアがそれを実行可能なテストコードに落とし込む。Cucumberなどのツールは「日本語のシナリオ」をそのままテストとして実行できる仕組みを持っている。

ゼロにはならない。BDDが防げるのは「仕様の認識違い」によるバグ。書かれたシナリオ以外のケースや、パフォーマンスの問題までは防げない。ただ「そもそも何を作るべきか」のズレが減るだけで手戻りは大幅に減る。

実際そこは課題。シナリオが増えると実行時間も長くなるし、仕様変更のたびにシナリオの書き直しが発生する。だから現場ではBDDは重要なユースケースに絞って使い、細かいロジックの検証はユニットテストに任せる「テストピラミッド」の考え方と組み合わせることが多いよ。