TDDとBDD/ATDD(2)　2種類のBDD

はじめに

前回は、テスト駆動開発（Test-driven development、以下TDD）とは何か、TDDの目的は何かについて話しました。今回は、振る舞い駆動開発（Behavior Driven Development、以下BDD）が考案された経緯と、specBDDとscenarioBDDという2種類のBDDの違いについて説明します。

BDDの誕生

BDDはDan Northによって考えられたものです。2006年に自身の記事「Introducing BDD（邦訳：BDDの導入 – Dan North）」でBDDという考えに至った経緯が述べられています。

Danの考えたBDDでは、TDDのルールから2つの変更を入れました。

・クラス名やメソッド名から「test」という単語を取り除く

・テストメソッド名は「should」という単語で始める（日本語の場合、『〜〜すべき』という単語で終わる）ようにする

これによって、より「振る舞い（特にユーザー視点での振る舞い）」に注目するようになりました。

Danによると、コードを変更してテストが失敗した時には、以下の3つに分類できます。

・バグを埋め込んでしまった。悪い子だ。解決法：バグを直す
・意図されたふるまいは変わらず関連性があったが、どこか別の場所に移されていた。解決法：テストを移動し、場合によっては変更する。
・ふるまいがもはや正しくない。システムの前提が変わってしまっている。解決法：テストを削除する。

BDDの導入 – Dan Northから引用

このうち、3つ目の解決法「テストを削除する。」に対して、BDDは大きな効果をもたらします。

元々のTDDでは、「testメソッドを削除する」という行動になってしまい、「本当にテストを削除して良いの？大丈夫？」と不安になります。これは前回話した「TDDによって品質を保証している」という誤解によって、testメソッドそのものの削除に対して非常に億劫になってしまっているからです。

一方、BDDではその心理的ハードルを低くしています。「振る舞いが違うのであれば、『should』で始まっている振る舞いの定義を削除した方が良いよね」という考え方に持っていこうとしています。

Liz Keoghは有識者との議論の中で、「『テスト』という言葉を使用する際の問題は、誰もが自分が何をテストしているのかを知っていると想定していることです。」と語っています。逆を言うと、BDDは事実を知らないという前提に立ちやすいと言えます。

振る舞いに注目することのメリット

BDDによってユーザー視点での振る舞いに注目すると良いことがもう一つあります。振る舞いに注目すると内部構造に注目せずに済む可能性が高くなります。これは、TDDではあまり得られない（得ることは可能だが、なかなか得ることに気付きにくい）効果でもあります。

例えば、自動販売機についてのプログラミングを考えた時、振る舞いに注目していない例として以下のようなテストコードを書くかもしれません。