TDD
プロダクションコードを書くのを引っ張ってくれるテストのことをDeveloperTestと呼ぶとして。一歩一歩、先にそれを書いてからRed→Green→Refactorのリズムでプロダクションコードを書く。
DevTestは、後でプライベートメソッドにするものも僕はテストしたりするんで、結構細かく大量になってしまう。なので、大切なのは、テストのリファクタリング。それやってないと「テストがあるから開発スピードがあがらない」とかいう状態になってしまう。負債。
下から積み上げて書いていくと、最後には、同じようなことを上のメソッドでもテストしてたりするので、「よし、このクラスの開発終わったー」ってなったら、そのあとにテストのリファクタリングをする。DevTestをUnitTest化する。と僕は呼びます。ま、クラスといわず、レイヤー間とかコンポーネント間のインターフェイスに対するテストまであげるときもあったり。
開発を引っ張ってくれたテストを元に、クオリティをキープしてくれるテストを作る。という感じ。
BDD
これで、ユニットテストはできるんだけど。それだけだと、「部分」のテストはできてるんだけど、実際はその「部分」を組み合わせて「全体」を作るんだけど、その「全体」のテストが必要で。
僕はホワイトボックステスト的に、カバレッジを見ながら、振る舞いのテストを書きたいので。僕はこれをビヘイビアテストと呼ぶことにした。
あ、誤解のないように言っておくと、ビヘイビアテストという言葉は存在していて、テストに詳しいデベロッパーが議論をしていて、たぶん定義もある。だけど、僕はその定義も知らずに勝手に言葉をかりて、このテストのことをビヘイビアテストと呼んでる。ということね。
最終的にはこのビヘイビアテストがあれば、振る舞いは保証される。c0とかc1とか聞かれても知らんけど、分岐はできるだけ通りたい。
ATDD
ビヘイビアテストまで書いてたら動きは保証できるのだけど。そもそも、要件を満たしてるかどうかって部分があると良さそうだなって最近思いだした。「あー、それそういう意味じゃなかったんよ」ってならないように。
「できたよー」ってプロダクトオーナーに見せるときに、あ、出来上がってなくてもモックアップを見せるときでもいいんだけど、プロダクトオーナーがチェックしてくれて、「おっけー、いいね」とか「あー、ちょい違う」とか言うときに。それって判断する基準があるんよね？か、ものを実際にみることで、判断が生まれるんよね。で、それって、テストじゃね？
あと、デベロッパーから、「ここんとこ、こうしたら良さそうかなーっておもったんだけど、どう？」って提案したりもするけど、「それいいね！それでいこう！」ってなったなら、それってOKかNGかかけるんじゃね？ってテストじゃよね。
DevTestや振る舞いテストはコードで書くんだけど。このAcceptanceTestは言葉で書く。あ、これもオレオレワールドの呼び名ね。
「このボタンを押したら、画面がぬるっと左にスライドして、商品画面が表示される」とか。スクラムでいうところの、ストーリーに対するAcceptanceCriteriaに書くような感じ。
大切なのは、ゴールを明確にすることであって、責任を押し付け合うために書くんじゃないよ。PO中心がいいと思うんだけど、みんなで作るんよ。最初から揃ってるわけじゃなくて、徐々に出来上がっていくときもあっていいと思うし。
んで、ビヘイビアテストは網羅的にしたいんだけど、このアクセプタンステストは、網羅的にはしない。穴だらけでいい。ユーザー目線で、この機能って、こういうことよね！っていう認識合わせができればいい。
まとめ
アクセプタンステストで、要件をテストできる形にして。それを満たすようにプロダクトを作る。これは、コードではなくて、文章でいい。
デベロッパー目線では、エラーハンドリングなども含めて振る舞いテストで網羅的にテストをしてクオリティを保証しておく。
いきなり振る舞いテストを満たすコードを書くの大変だから、DevTestから始めて、一歩一歩確認しつつ、ユニットテストに昇華させて、あとから修正しやすくしとく。
そんな感じ。
なんだけど
最近は、TDDは頭の中で済ますことが多い。んで、後からユニットテスト書いてる感じ。もちろん、0か100かという話ではないので、足下が不安なときはテストを先に書くときもある。
不安がない場合には進む。
て話を
昨日伊藤さんとしてたら、「Specification By Example読むといーよー」って教えてもらったので、読みたい。
