繰り返し可能なテストはそれだけでも十分よくできていますが、 別の目的にも使うことができます。 一枚の絵が何千もの言葉より雄弁なことがあります。 プログラミングにおいても、 コードの使用法を示すよいサンプルがあれば それは何千もの言葉に匹敵するものとなるでしょう 。 繰り返し可能なサンプルは機能テストとしても優れていますが、 ユーザや他のプログラマに対してソースコードの正しい使用法を示すという意味合いもあります。
ここで、いわゆるユニットテスト やテスト駆動開発 を例にして考えてみましょう。 あなたが書くことになるひとつひとつのサンプルは、 ソースコードが持つ振る舞い (behaviour) のある側面を表すものになります。 たとえばその振る舞いがどのような場合に発生するのか、 その結果どのような影響が出るのかといったことを表します。 振舞駆動開発 では、これらのサンプルのことをスペック (仕様) と呼びます。
BDD では、読みやすい形式のサンプルを書くことを推し進めています。 流れるように書けるドメイン特化言語 を用いることで、作成したサンプルのドキュメントとしての価値も向上します。 次のふたつの例を比較してみましょう。 2 番目の例のほうが、明確で読みやすく感じられるはずです。
コードのサンプルは、単なるテストだけではなくそれ自体がドキュメントにもなります。 サンプルを書くときには、できるだけ自然な英語の流れに沿うようにしましょう。 そうすることで、明確で読みやすいドキュメントとすることができます。 各サンプルは、そのまま普通の英語の文章に戻せなければなりません。 たとえば、先ほどのサンプルは次のように書き戻すことができます。
Logger
- should have a file
ここで改めて言っておきますが、BDD というのは単に TDD の "assert" を "should" に置き換えただけのものではありません。 BDD が存在する理由はそんなところにはなく、 TDD と比べてよりシンプルな言語で書くことができるということにあります。