テスト駆動開発入門

テスト駆動開発入門

TDDって真面目に勉強したことなかったので読んでみました。
Amazonの書評では翻訳がひどいということがしきりに叫ばれていますが、別に我慢できないほどじゃないと感じました。慣れれば読めます。K&Rより100倍マシです……。

さて、テスト駆動開発ですが、私がこの本を読む前に持っていた知識は以下のような感じです。

• テスト・ファースト
• テスト手法じゃないよ開発手法だよ
• グリーン→レッド→リファクタリング→グリーン……

で、実際に本を読んでみると、上記の理解はあまりに浅すぎることを知りました。
以下、特に参考になった点を挙げていきます。

TODOリスト

TDDでは最初に書くのはテストじゃなくてTODOリストでした。最初に実装する機能について要件定義を行い、その要件を満たすためにはどういうテストを書けばいいか？　というところからスタートします。そしてTODOを実現するためのテストを実装し、そのテストが通るようなコードを書き、リファクタリングをしていく、という流れになります。
チケット駆動開発と併用する場合は、各チケットの説明がこの最初のTODOになるのでしょうね。
また、いずれやらなきゃいけないと思われるリファクタリングもTODOに記入しておきます。

ただ、テキストではこのTODOリストに普通に紙媒体を使ってます。重要なところは太字で書き、終わったTODOは打ち消し線を引く、なんてアドバイスまであります。しかも、終了したものも含めたTODOが多くなりすぎたら物理的に別の紙に写すそうです。
いくらなんでも今どき紙媒体はないだろ……という気がします。いいTODOソフトはスタンドアロンでもWebサービスでもいくらでもありますからね。
私はGMailのTODO機能を使ってます。使いやすくはないですが、シンプルですので家でコーディングするぐらいなら充分使えます。

テストケースもどんどんリファクタリングしていく

考えてみれば当然なのですが、今まで知りませんでした。建築において一時的な足場を構築する場合が多々あるように、テストも一時的なものが存在します。不要になったら削除して、テストもきれいに保っておく必要があるということですね。

一日のプログラミングの終わらせ方

この本では、「個人でプログラミングするときは、最後のテストは失敗にして終えるべし」と書いています。そうすることで、次にプログラミングするときにどこから手をつければいいかすぐわかるというのです。
これはちょっと目から鱗でした。
TODOリストに書いたりするよりよっぽど簡単でわかりやすいですね。
この方法を知ってから、「昨日どこまでやったっけ？」というのがかなり減り、すぐにその日の作業にとりかかれるようになりました。
ちなみにチームで開発しててリポジトリにコミットするときは別で、ちゃんと動くコードをコミットしましょうと書いてます。
そりゃ当然ですね……。

まとめ

この手法が思った以上に個人での開発に効果があるということがわかりました。
きちんとテストさえ書いておけば、いちいち手戻りが発生するようなケースが減るわけで、結局開発のスピードが上がります。さらに、真面目にテストを書こうと思うと必然的にきちんとした要件定義もしなければいけないわけですから設計のレベルも上がるわけで、いいことづくめです。
また、思ったより簡単だということもわかりました。
xUnitも、とりあえず assertEquals() 覚えとけば最低限のテストはできますし、この本の中にはxUnitをTDDで作るやり方も書いてますので、xUnitのない言語でも自分で実装できます。

やっぱり本は引用や孫引きじゃなく、ちゃんと原典を読まないといけませんね。