『実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる』を読んだ。2年前にテスト駆動開発について勉強しようと思った時には、まだハードルが高そうだったので見送った1冊 (ちなみにその時は『JUnit実践入門』で勉強した)。読みながら考えたことをtogetterに集めたっきりにしていたのを、改めて振り返って整理してみようと思う。
この本の主題は、タイトルの〈テスト駆動開発〉ではなくて、サブタイトルの〈オブジェクト指向〉だと思う。原著のタイトル "Growing Object-Oriented Software Guided by Tests" に対応しているのも、サブタイトルの方。
次のエピグラフが、オブジェクト指向設計とテスト駆動開発の関係を端的に表している。
何かを設計するときには、常にもうひとまわり大きなコンテキストの中で考えること。椅子ならば部屋の中にあることを考える。部屋なら家の中、家なら環境の中、環境なら都市計画の中。ここでいう「もうひとまわり大きなコンテキスト」がテストに対応する。
エリエル・サーリネン
この比喩が示すように、ソフトウェアをエンドツーエンドで設計するために、動くスケルトンを作る。つまり、ユーザにどう使われて外部システムどうインタラクションするかを考える。加えて、開発側が行うプロセスもエンドツーエンドで通してみる。つまり、コンパイルだけでなくデプロイまでどうするか考える。
テストを書くことのメリットは、「Note インターフェイスとプロトコル」でいうところのプロトコル――インターフェースどうしの関係やメソッドどうしの関係をどうしたって考えることだと思う。テストなしだと各メソッドのシグネチャに指向リソースが奪われてしまう。
複雑な依存をコツコツ調べて引数無しコンストラクタでインスタンスを生成して、適切な順と適切な値の組み合わせでSetterを呼んで状態を調整して、ようやく呼び出せるメソッドのいかに使い辛いことか。そう言えば、『レガシーコード改善ガイド』にもこんな章があった。
- このクラスをテストハーネスに入れることができません
- このメソッドをテストハーネスで動かすことができません
この技術を習得する上では、要件をインクリメンタルなスライスに分割する方法を学ぶ必要がある。分割する前のエンドツーエンドの要件を分析するのは、TDDよりDDD――本書より『実践ドメイン駆動設計』が得意とする領域か。