テスト駆動開発 (TDD)は、ソフトウェア開発プロセスを改善する有効なものとして、また正しく用いられると奥が深いものとして認められています。TDDは、その実践者に対して様々な恩恵をもたらします。この恩恵の一部はテストに関連するものですが、最も重要なものはそこにはありません。
TDDの実践者で経験を積んだ人々、特に他の開発者がそのプラクティスを学ぶのを助けてきた人々は、TDDの学習と導入に関するライフサイクルについて注意を向けます。
- 開発者はコードについてのユニットテストを、JUnitやNUnitのようなテストフレームワークを用いて記述し始めます。
- テストの量が増えるにつれて、開発者は自分の行った仕事に対する自信が高まるのを楽しむようになります。
- ある時点から、コードを書く前にテストを書くことで必要なコードだけを書くことに集中できるようになるということに開発者は気づきます（あるいはそのように教えられます）。
- また、しばらく見ていなかったコードに戻った際に、コードがどのように機能するかを示すドキュメントとしてテストが役立つということにも開発者は気がつきます。
- このようなやり方でテストを記述することが、自分が書いたコードのAPIを「発見する」上での助けになることに気づいたとき、重要な事実が明らかになります。
TDDは、ここでデザインプロセスになるのです。
TDDについての専門知識がある段階に近づき始めます。そこにおいて開発者はTDDがテストよりもふるまいを定義することであると気がつくのです。
ふるまいとはシステムを構成するコンポーネント間の相互作用に関するものであり、したがってモックの利用は高度なTDDにとって本質的なものなのです。
私たちはこの進歩を多くの開発者に見てとってきましたが、不幸なことにほとんどの人は、わずかな助けによって第4段階までは到達できるのですが、多くは第5、6、7段階において見いだされる多大な恩恵を得ることができないのです。
どうしてこうなるのか、人々がより早く良いものに出会う手助けをするために何ができるのかを考え始めました。 理解するにあたってこの進歩を詳細に見てみると、第1段階はテストに関連すると考えられますが、実は残りはそうではありません。このプロセスの残りのステップにおいては、テストの側面は二次的な関心事にすぎないのです。この学習プロセスの核心にある問題は、システムのふるまいなのです。開発者が自らが構築するシステムにおいて自信を得るのは、システムのふるまいが確認されたときなのです。
コードに先立ってテストを書くことによって、開発者は自分たちが開発しているシステムのふるまいの目的を定義しているのです。 システムのふるまいの目的を文章化したテストはそのシステムのドキュメントと同じように最も価値があるものです。テストにおいてコードのふるまいを明確に示すことにより、開発者はサービスの提供者ではなく消費者の立場からインターフェイスについて考えることができます。つまり、ソリューションの性質についてより抽象的に考え、そうすることで技術的な詳細を隠蔽しているのです。
このように、テストよりもふるまいに目を向けることは、TDDにおける真の価値に焦目を向けることです。そして私たちの経験によれば、それは本当に経験を積んだTDD実践者の証なのです。
TDDの初心者が、TDDが実はテストに関するものではないと気がつくのにしばらく時間がかかるのは、さほど驚くことではありません。TDDをとりまく用語体系がすべてテストの観点から記述されているからです。
ふるまい駆動開発 (BDD)の狙いは、この欠点に対処することにあります。システムにおいてテストよりもふるまいの側面に目を向けた用語法を用いることで、BDDは開発者の目を本当の価値へと向ける手助けをしようとします。この本当の価値は、最も成功したTDDにおいて見いだされるものです。
BDDは企業ユーザと技術者がそれぞれ持っているコンピュータシステムに対する異なる見方の間を橋渡ししようとします。これはTDDの成功に深く根差しており、Domain Driven Designのような考え方から影響を受けています。BDDが注力するのは仕様、デザイン、実装とシステムのふるまいの確認との間にある障壁を最小限にすることなのです。このようにして業務システムのインクリメンタルな提供を可能にしつつ、これらの極めて生産性の高いテクニックを用いることによってアジャイル開発になじみの無いチームでもすばやくスピードに乗れるようにしているのです。
BDDは極めて特殊な（そして小さな）語彙を用いることで伝達の不十分が発生することを最小限におさえ、皆が、つまり業務に携わる人や開発者、テスタ、アナリスト、マネージャが同じページを使うだけでなく同じ単語を使えるようにするのです。 ここで強調すべきなのは、BDDが既存の優れたプラクティスの言い換えであるということです。決して新しくラディカルな新機軸を打ち出すものではありません。この目的は良く練られた既存のテクニックを共通の旗印のもと、明確で一貫性のある用語によって統合することなのです。実際には、「単語の意味を正しくとらえること」がBDDの開発におけるスタート地点となっており、また今でもその中心であり続けています。「単語の意味を正しくとらえること」は、正確で使いやすく、記述力に富み一貫性のある語彙を作り出すことを意図したものです。
原文：Introduction
last edited 2009-08-07 22:11:18 by DanNorth
翻訳：YukeiWachi