テスト駆動開発 書評

テスト駆動開発を読み終わった。評判通りの良い本だった。

テスト駆動開発

ソフトウェアを書くときにテストフレームワークを使ってテストを書くことはやっていたが、きちんとテストファーストで書いたり(実験的にそういうことをやろうとしていた時期はあった)、体系的に学んだことはなかった。内容がテスト駆動開発(TDD)だけにフォーカスしているのもよさそうで手に取った。

TDDとはなにか

まえがきがとてもシンプルにTDDとはなにかに言及しているのがよい(まえがきをペラペラと数ページ読んで購入を決めた)。

• 自動化されたテストが失敗したときのみ、新しいコードを書く。
• 重複を除去する。

これが実践できるようになれば本の重要なことの50%は達成できたといってよい。(しかしそれを現実のソフトウェア開発でやるのが難しい。)

どのように進めればうまくいくのか？以降に実例を挙げて説明されていく。

• レッド、グリーン、リファクタリングを繰り返す。
• TODOリストを作り、目の前の問題だけに集中する
• テストは最後にパスするべきアサーションから書いていく

実際にコードを書きながらコードとTODOリストを育てていく様も見ることができるのが個人的には嬉しかった。(自分はちょっと大きめにTODOのタスクを切り出してしまう癖があることを発見した。)

TDDのスキル

ネットの情報を漁ると、なぜテストが重要なのか、どのようなツールを使うとテストをかけるのか、といった情報が多い。しかし実際にテスト駆動開発を始めようとすると必要な知識はその先になる。

書籍にはうまくテストを書いていくには何に気をつければよいのかの例がたくさん書いてある。

• まずは仮実装としてベタ書きの値を返すことでとりあえずテストを通してしまう。
• 高すぎず低すぎない階段を作るように1つずつテストを書いていく。
• 三角測量、2つのテストから1つの実装を導き出す。
• LogStringパターン、実行した関数名を文字列に追記していくことで関数が正しい順番で呼ばれていることをテストできる。
• はじめのテストで書くべきものは何か。
• コレクションの操作をテストするときはまず単数を対象にしたテストを通してからコレクションでも正しく動くように育てていく。
• 1回のテスト、実装、リファクタリングのループは15分から30分が目安。

「フィクスチャー」など専門用語の意味も書籍のお陰で分かった。

訳者解説

あとがきの訳者解説も面白い。

TDD初期から最近までのテストにまつわる歴史や訳者の見解がぎっしり書かれている。

原著は割と古い本なのだがこのあとがきのおかげで最新技術とのギャップを上手く補完してくれている。(とはいえ、原著の内容はほとんど古さを感じることはなく、私自身あとがきを読むまで気がつかなかった。)

個人的には”TDD is dead, Long live testing.”がどのような文脈で出てきた記事なのかが分かったのがよかった。

「教条主義化と意味の希薄化」は技術が盛り上がったときにどこでも起きうる現象なので気をつけたい(いい言葉を知った)。

まとめ

全体を通して感じたのはTDDとは考えることを少なくするための技術だということだ。

テストを書くときはテストのことだけ、実装のときは実装だけ、リファクタリングのときはリファクタリングだけに集中する。それを繰り返すことで大きなソフトウェアになる。ソフトウェアが大きくなったときにはすでにたくさんのテストコードがあるので安心して修正できるようになっている。

派手な技術ではないが、堅実に長くソフトウェアを作るのに大変役に立つ。