「アプリケーションをどのようにテストすべきか？」という書籍は過去に読んだことがあったが、テストそのもののメンテナンスなどに関する本は初めて読んだ。
これまでの経験則からわかっていたことが言語化された面もありつつ、自分が考えたこともなかった側面も明らかになり非常に良い本だった。 加えてこの本が出版される直前に、同僚が書いたテストコードの粒度があまりにも細かくて苦労したために恐ろしく納得感があった。(実装の詳細を細かくテストしていたためにリファクタリングへの耐性がなかった)
一方でこの本が提示している単体テストのあるべき姿を適用しようとするとプロダクションコードをテストしやすい形にする必要があるため、一朝一夕でこの本通りにやるというのは無理そう。
またこの本に限ったことではないが、コード上の表現と実際の概念の違いを意識するのはかなり大事だと再認識した。
たとえば、あるクラスAのメソッドaがpublic（公開）であるとして、クラスAを含む複数のクラスがまとまって1つの振る舞いを提供するモジュールを考えると、メソッドaは「公開されている振る舞い」ではなく「実装の詳細」であるとか。 interface や抽象クラスだから「抽象」なのではなく、「重要ではない詳細を除いた単純化されたエンティティのビュー」が「抽象」だとか... (よって関数のシグネチャも抽象化の一つであるという話)
以前どこかで見かけた「一番変わらないと自信があるインターフェースに対してテストを書く」という案は結構納得感があったなと思い出していた。
