ケント・ベックの「テスト駆動開発入門」を読んだ。今まで３回チャレンジして、ようやっと読み終えた。
テスト駆動開発とは、僕なりに書けば以下の手順で進める開発手法のこと。
- これから作るプログラムが満たす条件をテストとして書く
- テストが動くようコンパイルが通るだけのプログラムを書く
- テストをする（コンパイルが通るだけで1.の条件は満たさないので失敗になる）
- テストが合格するまでプログラムを書く
- 1.から、より本質的な条件のテストを追加して繰り返す
1. で作るプログラムのインタフェースをテストの形で明らかにして、2. と3. でプログラムを書く準備をして、4. でインタフェースに沿ったプログラムを作る。これをプログラムが要求仕様を満たすまで5.で繰り返す。
今回読んで感じたのは、プログラムを完成させることよりテストを合格させることに重きをおいている、ということ。テストは具体的な数値から始めて、テストを合格するだけの簡単なプログラムを書く。5. の繰り返しで徐々に抽象度を高めながらプログラムを完成させていく。なるほど「テスト」によって「駆動」されている。
テスト駆動開発が出るまで、テストはプログラムのホコリタタキというイメージがあったと思う。だからプログラマにとって、テストは愛着を込めて作り上げたプログラムを叩く工程という気がして、マイナスイメージだった。そのためテストはイヤイヤだったと思う。
だけどテスト駆動開発では、プログラムを書きながらテストを次々に合格させていく。プログラムとテストがゲームのようになって、より楽しくなるのだと思う。あと、プログラムを書く前にテストという形で仕様が明らかになるから、プログラムを作っているときに「あれ、ここどうするっけ？」ってなって後戻りすることが減る。
１つだけ気になるとすれば、テストよりプログラムを書くのが楽しいプログラマにとっては、プログラム本体を書くことをグッと我慢して、まずテストを書かなければならない。プログラムを書くときは「要求をいかに実現するか」っていうパズルの面白さを感じるので、この我慢はつらい。修行だね。
テスト駆動開発入門には、テスト駆動開発のやり方だけでなくテスト駆動開発のノウハウがデザインパターンとして紹介されてる。個人的には、第26章 レッドバーに関するパターンにある
面と向かってTDDを押し付けることほど、TDDの普及を妨げる行為はない。
というのが強く印象に残った。
これまで３回読むのにトライしたんだけど、今まではリファクタリングとか xUnit とか、テスト駆動開発を実現するための手段に目が行って、本質を見られてなかった。だから、目的がよく分からなくて面白くないなぁと感じていたと思う。
