じゃあ、”テスト”はいつ書くの？

BDDの考え方には概ね賛成なのだが、しかし待てよと考えた。
自分のこれまでのTDDスタイルはまずクラスのスペックをテストコードとして記述し、スペックをパスする実装を書いた後にホワイトボックステストとしてのテストコードを書いていた。
スペックを書いて実装を書くまでがTDDで、ホワイトボックステストはxUnitを活用した品質保証のためのテストである。
以前、ペアプロでやっていた時はパートナーに「よし、じゃあここからはいわゆるテストを書こう」なんて言っていた記憶がある。

BDDになるとホワイトボックステストを書かないようにならないだろうか？
テスターにお任せ？
でも、ホワイトボックステストなんて実装者じゃないと書けないよ。
rspec,jBehaveなどのBDDフレームワークでもホワイトボックステストは書くことはできるだろうけど、主旨が違うわけだし。

ということで簡単な解決策として、BDDフレームワークにいわゆるテストの語彙も入れてしまう。
で、スペックを書いている時とテストを書く時で使い分ける。
「よーし、まずはBDDでスペック書いちまおうぜ。そしてこれが動くように実装だ！」
「OK。BDDのおかげでいけてる設計になったじゃないの。じゃあ、こっからはテストね！」
なーんて感じ。

今あるフレームワークで解決策を考えるのであれば、私としてはjBehaveのストーリー、シナリオという考え方をBDDとして活用し、それ以降はこれまで通りのTDD&ホワイトボックステストでいきたい。
でも、jBehaveにはJUnitの拡張もできるみたいだから、上記のアプローチでもいけるかも。
うーむ、調査が必要だな。