オーム社さまから電子書籍を贈本いただきました。ありがとうございます。

本書はテスト駆動開発（TDD）の原典で、たいへん有名な本です。が、自分は食わず嫌いで読んだことがありませんでした。

というか、TDD 自体もちゃんと理解したことがありませんでした。なんだろう、なんか怖かった。

そんな自分が今回この本をいまさら読んでみたら、なるほどこれは確かにいい本でした。なんというか、語りたくなる感じ。ということでご紹介。

紹介 テストとプログラムを交互に書いていく開発方法 TDD を、例題を用いて実演していく本です。 TDD というと「プログラムより先にテストを書く」というところだけ強調されますが、正直それではよくわからないのでした *1 。本書によると、 テストを 1 つ書き足す それをパスする仮実装を追加する 仮実装をまともな実装にする を細かく繰り返す、というものだそうです。仮実装は本当にテキトーで、テストの期待値をそのままプログラムに埋め込んだりします。「仮実装をまともな実装にする」は、本書では「テストとプログラムの間で重複を省く」と表現されています。というのも、プログラムに期待値を埋め込むことで、その期待値がテストとプログラムの間で重複するので。この重複をいい感じに省くことで、徐々にまともな実装になっていく。 「テスト駆動開発」という名前ですが、テストを書くための方法ではなく、あくまで設計開発の方法ということがよくわかりました。テストはあくまで実装のガイド。テストはそえるだけ。 構成としては、第 1 部は通貨の足し算や掛け算を扱うプログラムを Java で、第 2 部はテスティングフレームワークを Python で、それぞれ TDD の実演で開発してみせます。上記の繰り返しそのときどきの思考が、なんというか非常に生々しく書かれていて、ライブ感に溢れています（訳者あとがきで「まるで Kent Beck とペア・プログラミングしているかのような体験をしました」と書かれていて、まさにそんな感じ）。第 3 部は TDD にまつわる色々な話題を集めていて、まえがきによると「リファレンスとして使うのがよいだろう」だそうですが、自分の印象としてはエッセイ集みたいな感じです。ただ、第 3 部はまだ流し読みしかしていないので、あとでちゃんと読む。 本書自体も（読んだことのなかった自分には）面白い内容でしたが、この翻訳には訳者の t_wada さんによる「訳者解説：テスト駆動開発の現在」という付録がついてます。TDD の原著が出てから現在までの歴史と現状が非常にコンパクトにまとまっていて、さらに現代で TDD とどう向き合っていくべきかが書かれています。ここの良さを説明するのは困難ですが、とりあえず、自分が TDD を強迫観念みたいに感じていた理由と、別に怖くない（人もいる）というのがよくわかりました。

所感 まあ、自分が TDD を実践したくなったかと言うと、そうでもないです。TDD の真のポイントは TODO 管理だと思うんですよね。仮実装が一部仮のまま次のテストに進むことがあったり、テストとプログラムの間で頻繁にコンテキストスイッチしたりするので、TODO を忘れずにこなせる人でないと厳しそう。普段の生活でも TODO 管理が辛いのに。 とはいえ、テストをパスする状態を維持するというのは強く共感しました（というか、こういう本などが布教した考え方なんだろう）。Quine を書くときも、まずはでかくて不格好でもとにかく動く Quine にし、そのあとは動く状態を維持しつつ形や長さを改良する修正を少しずつやっていきますよね。うん。あと、こういう頻繁にテストを実行するやり方では、コンパイルに数秒もかかるような言語処理系では無理だよねー。 それから、TDD が別に万能ではないことがちゃんと書かれているのが好印象でした。設計のひらめき自体は TDD では得られない（83 ページ）とか、アサーションで使う述語自体が間違ってたら TDD は無力になる（27 ページ）とか。あと、通貨換算の責務は Expression ではなく Bank に持たせたい（83 ページ）と言いつつ、その後はせっせと Expression#reduce を実装してたり、最適化を実装しようとしたものの抽象度が壊れるから諦めて（128 ページ）、「パフォーマンスの懸念もあるが、実際の使われ方を見てから最適化を考えるので十分だと思う」（135 ページ）とか強がるあたり、ニヤニヤしながら読めた。そんな気取らない作風でした。