BDD | Project Background - PicklesJar/pickles GitHub Wiki

BDD とは、ビヘイビア駆動開発(Behavior Driven Development)のことです。

Wikipedia を読んでもらえばわかるとおり、Behavior とは振る舞いと訳し、実装する前にテストコード、それも自然言語に近いコード、もしくはテストコードを制御するための自然言語で書かれた付属資料などとテストコードを作成する開発手法のことです。

BDD は TDD(Test Driven Development) から派生したものなので、その特徴は TDD とほぼ同じですが、テストコードが自然言語に近いということが相違点となります。(TDD は少しづつですが日本でも拡がりを見せているので、馴染みがある人もいるかもしれません。)

自然言語で記述されるので、プログラムが読み書きできない人でもそのテストが何をしようとしているかを容易に把握できるのです。

// だからといって、プログラマ以外の人でもテストに参加できる!!と考えてはいけません。残念ながら、自然言語が読み書きできても論理的思考ができるとは限らないのです。

TDD についてもふれておきます。端的に言えば、TDD とは、先の BDD の説明にある「実装する前にテストコード...を作成する開発手法」の部分です。文字通り実装する前にテストコードを作ってしまうのです。

何故こんなことをするのか、疑問に思う人もいるでしょう。これを理解してもらうには、自動テストが普及し出した頃からの話をするべきだと思います。

いわゆる nUnit(Java では jUnit) が多くの人に知れ渡ると、人の代わりにテストを自動で実行してくれるこのシステムに多くの開発者が胸をときめかせました。なにせ、一度テストコードさえ作ってしまえば、寝ている間も勝手にテストをしてくれるし、デグレード、リグレッション確認のために何度も同じテストをやらずに済むのですから。

そこでしがらみの少ないオープンソースや個人から小規模事業者の新規開発プロジェクト、中規模の事業者へとその導入は加速度的に増えて行き、その有効性が認められると共に関連するツール、ソフトウェアなども増えて行きました。しかし、残念ながらそのままデファクト・スタンダートとはなりませんでした。中堅から大企業など SIer が関与する開発案件などで導入を検討しても多くの場合に不採用となり、導入が急激に鈍化してしまったからです。

テストの自動化はメリットが大きい反面、大きなデメリットを持っています。その最たるものが、テストコードの作成は一般に製品となる実装より多くのコスト（工数）が必要となることです。一般に製品となる実装の 1.2 倍と言われるこのテストコードの開発工数は、SIer が顧客企業に支払いを納得させるにはあまりにも大きなコストです。いくら先々楽になるといっても、今それを簡単に納得してくれる企業は多くはないのです。

// これは顧客企業の多くが長期的なシステム開発に対して戦略を持っていないという問題で、一朝一夕に好転しないです。（残念ながら多くの企業は、それは SIer の領分と誤解しています。）また、SIer でも一部の元請け企業では新しいものを導入すること自体をタブー視していることもあるので、業界全体の問題でもあります。

このような経緯の下、特に日本の開発現場では、個人、中小規模の企業における開発プロジェクトでは自動テストやそれに関連する CI システムなどを含めたツールの導入が進む一方、大規模開発の現場では、テストが必要な度にテスト項目書を作成し、（デバッガを利用するなどしても）人力でテストすることが主流になってしまっているのです。