新しい職場の仕事用に Jenkins を使い始める事にした頃、
題材としてテスト駆動開発(TDD:Test Driven Development)の勉強も始めた。
そして、半年程度の開発期間中に、何度もデグレを発見して、間違いなく助けられた。
テスト駆動開発は正しいのだ。
だけども、今の職場には根付かず、殆ど自己満足に終わった。
事前に設計仕様書や実装仕様書を書くことが無い今の職場では、
テストに説得力がないし、後から出来た仕様書と整合性を取るのは不可能に近かった。
いやいや、これではTDDになってないぞ。
テスト仕様書を元に設計仕様書が提案出来ないものか。。。
そんな事を思った人が多かったらしく。(汗)
TDDから発展した振る舞い駆動開発(BDD:Behavior Driven Development)という考え方が出て来たそうだ。
TDDでは、(仕様書か頭の中にある)仕様に合っているかどうかをテストする。
BDDでは、仕様自体をテストする。
テストコードを書く時点で「どこかにある仕様」が正しい保証がある訳じゃないんだ。
BDDなら、テストコードと(未来の)要求仕様とが直接的に繋がっている。
上手に使えば、テストコードから仕様書を作ったり改善したり出来るはずだ。
早速、PHPの勉強ついでに、BDDを試してみよう。
振舞駆動開発 BDD とは？
Wikipediaのビヘイビア駆動開発 によると。
『これから作成しようとするプログラムに期待される「振る舞い」や「制約条件」、
つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する』
従って、テストコードの可読性があがるし、テストコードが要求仕様となり得る、ということ。
これだ！欲しかったのは。
そのためには、
いくつか守るべきコンセプトがある。
Executable Specification
実行可能な仕様？
テストするのだから、当然、ひとつひとつが実行可能な範囲でないと。
と言うことかな？
Tests as Documentation
テストコードがそのままドキュメントになり得るよう、
自然言語の文章に近い形式で書く。
テストの可読性が上がり、振る舞いが分り易くなり、
そして、これ自体が詳細仕様書になる。(かも知れない)
Specification by Example
例示を基にして、仕様を見つけていく作業。
作業としては、TDDと違いないかも？
BDDの具体的なテンプレート
- 「Given xxx. When yyy. Then zzz.」：「xxxであるときに、yyyすると、zzzになる」
- 「Given」：事前状態を表現する
- 「When」：刺激や操作を表現する
- 「Then」：事後状態を表現する
- 「x should y: テスト自体を「対象（x）がどうである（y）べきか？」と表現する
振る舞い以外を自動テストはするべきではない
内部構造に依存したテストでは、実装したコードの変更にテストが影響されてしまう。
PHPで使える振舞駆動開発フレームワーク
有名どころでは、
PHPUnit + PHPUnit_Story か、PHPSpec 。
なのだけど、どちらも既に開発が止まっている。
3年くらい前に流行が終ってしまったらしい。
ここまで調べておいて何だけど、
乗り遅れてしまったようだ。