BDDとTDDはどう違うのか？

以前BDDとTDDはどう違うのか？という質問をされてうまく答えられませんでした。

現在私がBDDで好きだなと思い、TDDと異なると思うのは、BDDはとにかくまずプログラムに何をさせたいかを伝えることです。

暫くRoRとBDDで実践をしていて、決済のAPIを導入することがありました。最初はAPIの仕組みを調べてAPI指定のコマンドを直接コントローラに記述する形で、例えば

gateway = | PaypalApi::Billing.gateway
setup_purchase = gateway.setup_purchase
if setup_purchase.success?
  redirect_to gateway.redirect_url_for(setup_purchase.token)
else
  redirect_to somewhere-else, notice: "transaction failure"
end

などとしていたのですが、これだとテスト用APIのモックやスタッブを書くのがとても面倒。BDDではこのアプローチをやめて、とにかくAPIの仕様など気にしなくてプログラムに何をさせたいか書く事から始めるとすっきりします。例えばモデルのインスタンスを@orderにしている場合、

if @order.setup_purchase
  redirect_to gateway_url
else
  redirect_to somewhere-else, notice: "transaction failure"
end

としてモデルの中で実際にsetup_purchaseのコードを書きます。こうするとコードもテストコードも整理しやすくなります。

ただ実際はコントローラからtokenなどのpostリクエストの部分をモデルに渡す必要があるところで後でメソッドに引数を追加する必要など私の場合は出てきましたが。

BDDのコアコンセプトは？

BDDのメソッドは何となく面白いので使ってみたいと思うのですが、その基本となるコンセプトは何か私なりにまとめてみました。

 

上のメモのように、つまりユーザー(もしくはオブジェクトなど)のリクエストというbehaviourが発生した時にソフトウェア(API、オブジェクトなど何でも) がどのようなレスポンスを返すかということに集中して開発をするということだと理解しました。

 

データベースのリレーションや、ソフトウェアのロジックは後回しにして、これをするとこういう動きが返ってくるべきだという地点から全てを開始するということですね。

 

Test Double について

TDD, BDDは使い慣れていない用語や普段使っている言語とは異なるソフトウェアサイエンスでの用法があるので、用語の理解が一つのハードルであると感じます。

この辺りはかなりソフトウェアエンジニアリングではなく、ソフトウェアサイエンスの領域に入ってくるんでしょうね。最近はビジネスに関連してソフトウェアエンジニアリングのアプリケーションばかりをしていますが、学生の頃にはサイエンスの方をしていたのが懐かしく感じます。

"Test Double"もその一つではないでしょうか？"Test Double" G. Meszarosという人が考えた言葉なそうです。本人の書いた記事にその内容が書かれています。是非オリジナルを当たってください。個人的に著者の言葉の使い方にはprecisionが欠けている箇所がある気がしますが。

Doubleというのは英語ではいわゆるそっくりさんのことですね。G. Meszarosの原文ではスタントマンを例にとってきています。上の図に表される様にG. Meszarosの定義では、Test DoubleにはTest Stub, Test Spy, Mock Object, Fake ObjectとDummy Objectが含まれます（このDummy Objectは正確にはTest Doubleには含まれないそうですが）。要は"Test Double"とはこれらの用語を総称した言葉ですね。

用語
SUT: System Under Test テスト対象のシステム
DOC: depended-on component 異存しているコンポーネント
indirect output: 公開APIでは見れないが、他のコンポーネントに送られているSUTからのアクション

以下、それぞれの意味というか使い方です。

- Test Stub: SUTから送られてくるメッセージを受け取るために使用。indirect outputを正常に受け取らないとSUTが正常に動作しないなどの場合に使用。

- Test Spy: SUTから送られてくるメッセージを受け取るために使用というのはTest Stubと同様だが、Test SpyはSUTから送られてきたindirect outputの内容を記録して、後でバリデーションに使用できるようにする。

- Mock Object: Test Spyと同様に使用。原著からは私はTest StubとTest Spyの違いが見つけられませんでした。

- Fake Object: 実際のDOCの疑似コンポーネント。実際のDOCと似た動きをするが、まだ実際のDOCが用意できていない時に使用する。また、実際のDOCではデータベースの読み込みに時間がかかりテストに適していないという場合には、Fake Objectのハッシュオブジェクトにデータを収納してテストに用いる。

- Dummy Object: SUTがパラメータにオブジェクトを必要とするときに渡すオブジェクト。中身の無いメソッドを実装したnull object 参照でも問題無い。Dummy Objectは原著では厳密にはTest Doubleではなく、Literal Value、Derived Value、Generated Valueに属するとされている。

RoR開発環境でのTDD, BDD導入書籍

TDDはとても良さそうだと思い、RoRのDSL (Domain Specific Language) であるRSpecを調べていくうちに書籍の紹介ブログを経てBDD (Behaviour Driven Development) に行き当たりました。TDDに関する書籍はJavaのコードを用いているものが多く、Rubyを主に使っている私にはとても便利です。RubyやRailsを使っている人が書いている本だけに文体もポップです。

BDDとは、もっと人間の目線をプログラム開発に導入していくということなのでしょうか？TDDがプログラムの挙動を予想、テスト、リファクターするのに対して、BDDはあるユーザの行動を予測、テスト、リファクターという視線で開発を進めるということではないかと理解しています。

BDDはプログラム開発のあらゆる過程で便利そうだなという気がしています。ただ学ぶことは多いですね…

”バイオコンピュータ”などという言葉が当たり前になっている頃には、”これをこういうタイミングでやって”と言葉で表現すればコンピュータが実行してくれるので現在のプログラミングという仕事自体の幅がかなり狭く一部の人しか必要とされなくなっているのでしょう。お払い箱になる、もしくはお払い箱になる前に新しい技術についていかなければならないというある意味脅迫観念は起きますね。