BDDってなんですか
いくつか記事を読んだ。読みやすかった順に並べると……
- テスト駆動開発のテストは、テストか?-TDD から BDD へ:An Agile Way:ITmedia オルタナティブ・ブログ
- text.ssig33.com - RSpec の書き方について
- Twitter / kyanny: context 入れ子にしてテストを階層化する -> ...
- UKSTUDIO - BDDについて自分なりにまとめてみた
でもこれでは正直よくわからない。テストの戦略にTDDやBDDはどういう意図・位置づけで組み込まれるのかを知りたい。
これでもまだよくわからない。
これを読むとようやく他のページと内容がリンクしてくる。
まるで仕様書や設計書であるかのごとくテスト結果がアウトプットされることによって、設計のブラッシュアップに大きく貢献する。それがBDD。
アウトプットされた文章がなんだかおかしい場合は、そのクラスにあるべきでない処理になっている可能性がある、とか。
でもこの記事は途中から要件定義/受け入れテストの話に変わっちゃうんだよね。。まあでもそれは、JBehaveを分析行程に応用できるのではないかと気がついたからそうなったのであって、つまりBDD支援ツールたるこのJBehaveは当初「進化したJUnit」のような感じでスタートして受け入れテストに着地したということらしく。。
だから4つめに紹介したページのように「TDDでありATDDである」ということになる。
別に要件定義や受け入れテストの文脈でBDDを調べたのではないので。。とりあえず単体テスト的な部分でまとめ。
BDDはTDDの壮大な言い換え。テストコードにBDD特有の語彙(shouldとか?)を使うことで設計のブラッシュアップに大きく寄与する。
ここから(たぶん)私見。細かいデータのレベルではTDDもBDDもテストで確認することは結局同じ、と言う意味でTDD=BDDといっても間違いではない。ただ、TDDは正にテスト項目を挙げることから全てが始まるイメージ*1なのに対し、BDDは振る舞い(シナリオ)を挙げることから全てが始まるイメージ。
このレベルの話だとどこまでいってもニュアンスの問題になる感じで腑に落ちてこない。だからrspecとか具体的なBDDツールを例示して「ほらこんな感じで設計にも役立つんだよ」って話にした方が理解するのもしてもらうのも省エネな気がした。
それでそれで。今私のいるプロジェクトはScrum+BDDで単体テストがあまりないんだけど、BDDを調べてみてもやっぱりScrum+BDDだから単体テストは緩くていいなんて話は全然出てこなかった。。だいたいBDDとしても不完全でrspecのコードはかなり不足しているし。
プロジェクトが始まる前に「単体テストやりすぎると生産性が上がらない」と言われたので単体テストがなおざりなんだけど、今のプロジェクトって品質担保についてどう考えているんだ。。ScrumというかAgileの方を勉強すれば考え方が見えてくるのかな? そういえば読んでないなScrumの本……