サンプルから先に書き始める理由は、ごく単純なものです。

まずはじめに、自分たちが直面している問題を把握することで これからやるべきことをはっきりさせるという効果があります。 スペックやテストを書かず、 堅いことを考えずにさっさとコーディングを始めようとしてしまい、 結局方向性を見失ってしまう。 誰でも一度はそんな経験があるはずです! 一方、サンプルを書くということは、 まず最初に公開 API をどのようにするかを検討しなければならないということを意味します。 また各部品間のロジックの流れや出力内容、実装に必要なロジックなども検討することになります。

もうひとつの効用は、 すこしずつ一歩一歩進めていくことでよりよいコードを書けるということです。 「仕様を考えてサンプルを書き、それを満たすコードを実装し、 リファクタリングし、そしてまた最初に戻る」 という一連の流れを細かく繰り返すことで、 よりよい設計のコードができあがるようになります。 その結果できあがったコードは保守しやすいものとなり、 またシンプルですっきりしたものとなるでしょう。 一般に、そのようなコードのほうがバグも少なくなります。

それ以外にもさまざまな利点がありますが、 中でも最大の利点は確信を持てるようになるということでしょう 。 自分の設計、コードの品質、プログラマとしてのスキルなどに自信が持てるようになり、 コードを変更する際にも怖がることはなくなります。 また、ソースコードがきちんと設計されていてテストが行われているということに対する 他のプログラマやユーザからの信頼も得られます。

普段のコーディング作業に BDD を適用する手順をまとめます。 サンプルを書いたらまず一度それを実行し、失敗することを確認するようにしましょう。 あとは、そのサンプルが成功するようになるまで実装を行います。

後で振舞駆動開発について説明するときに、 これらについてより詳しく取り上げます。 これは、TDD における「テストを書いて、コードを書いて、 そしてリファクタリングする」という手順に似ていますが、 BDD ではそれだけでなく ドキュメント/仕様 という観点も重視しています。本書では、テスト手法については特に取り上げません (作成したスペックがテストとしても有効であるというのは偶然の産物であり、 BDD の真の目的はよりよい設計を目指すということです)。