なぜ読もうと思ったか
ケントベックの書いた本が読みたい！と思ってだいぶ前に買ってずっと放置していた。ので読みました。
どのような本か
ケントベックがどうやってTDDをやるのかを解説している本。本の構成としてはPart 1〜3に分かれていて、Part 1と2は実際のコーディング例、3はパターンの解説となっている。
書評というかレビューというか感想
ケントベックはこうやってTDDやるのか！というのが分かる本。そういう意味では非常に面白い。作りたいシステムに対してどういう風に考えながらテストを書きコードを書いていくのか、その思考の過程を惜しみなく書き連ねているのが面白い。もちろん技術的な解説もあるし、後半はよりテクニカルな話題になっていく。三角測量とかモックとかフィクスチャとかデザインパターンとか。
個人的には、Part 1は面白かったがPart 2はめちゃくちゃ読みづらかった。というのも題材が「xUnitの開発」なのである。「xUnitを使ってテストをする」ではなくて、「xUnitそのものを開発する」である。普段からxUnit（あるいは類似のもの）を使ってテストするのが当然に近くなっている昨今、この題材は混乱を招きやすいと思う。xUnitっぽいコードが出てきたらそれはテストコードかと思ってしまう。でも実際はそっちがプロダクトのコードであってそれを今からテストして…あれっ、今書いてるのはテストだっけ？プロダクトのコードだっけ？みたいな感じになって辛かった。正直あまり内容覚えてない。。
とまあ文句も書いたけれども、TDDのサイクルをケントベックはどのように回すのか、それが知れただけでも読んだ意義はあったように思う。コード例やライブラリに関する記述がちょっと古いなーと思うことは多かったけど、2003年出版なので仕方ない。
その他いくつか面白いと思った部分を引用してみる。
よいエンジニアリングはプロジェクトの成功のうちのおそらく20%だろう。悪いエンジニアリングは間違いなくプロジェクトを沈めるが、普通のエンジニアリングの場合、残りの80%が正しく行われれば、プロジェクトは成功する。この観点から、TDDはやりすぎである。業界内の標準よりも欠陥が遥かに少ないコードと、遥かにきれいな設計を生成する。
これは正直意外だった。「TDDはやりすぎである」と感じている人は多いと思うが、ケントベック本人も（ある観点においては）そのように思っていたのである。なるほどなー。
TDDを開始することで、筆者自身のプラクティスのストレスが遥かに少なくなった。全てを１度に心配する必要がなくなった。このテストを動作することができれば、残りのテストも動作させることもできる。チームメイトとの関係が肯定的になった。ビルドを壊すことがなくなり、チームメイトは筆者のソフトウェアに基づいて動作することができた。システムのユーザも肯定的になった。システムの新規リソースは機能追加だけを意味し、古くからあるバグの中から新しい多くのバグを識別する必要はなくなった。
マジかよTDDすごいなおい。こんな経験してみたいものです。
その理由はテスト駆動開発で作業すると、１度に１つのボールを空中に投げているかのような感覚が得られるからだろう。そして、そのボールだけに集中して、本当に良い仕事を行うことができる。新機能を追加するとき、よい設計かどうかは気にしない。できるだけ容易にテストをパスさせるだけだ。リファクタリングモードに入ると、新機能の追加のことではなく、正しい設計にすることだけを心配する。どちらの場合も、１度に１つのことだけに集中する。その結果、１つのことをよりよくすることに集中できる。
なるほどなと思った。ちなみにこの文章はマーチン・ファウラーによる後書きからの引用です。
その他、付録2の「フィボナッチをテストだけから導出する」がとても良い。TDDが美しく適用される例として素晴らしいと思う。
最後に。正直に言うと、文章が読みづらくて常に辛さを感じていた。具体的に何故かはわからないけどキツかった。和訳の仕方との相性があるのかも知れない。
よくよく調べてみると「テスト駆動開発」と言うタイトルで2017年に新版が出ているようなので、こちらを買った方が良さそうです。翻訳はあの和田卓人さんだしきっと読みやすくなっていると思う。付録に古い記述をカバーするような内容もあるらしいし。未読なのでリンクは貼りません。
一応、こっちの版のメリットとしては中古本が激安で手に入ることでしょうか。金銭的リスクを極限まで下げたい人はこっちを買ってみてもいいかも知れません。
次はXPの本でも読もうかな。
