単体テストの考え方/使い方 (Vladimir, (2022)) を読みました。2022年末から話題になっていて、Amazonでは品切れの状態が続いていた本です。物理書店に行くと割と置いてあるみたいです。自分も年末に物理書店で購入し、興味深く読みました。

さて、この本は単体テストの質を高め、ソフトウェアに価値をもたらすための本です。

ソフトウェアに価値をもたらす単体テスト

単体テストには、ソフトウェアに価値をもたらす単体テストとそうでない単体テストがある、というのが本書の主張です。そして、ソフトウェアの成長を支え、価値をもたらす単体テストを書くためにはどうすればよいのか、ということが論じられています。

わかりやすい例でいうと、プロダクトコードをリファクタリングした時に（壊れるべきでないのに）壊れてしまうテストは、価値が低いです。本書では、こういったテストをリファクタリングに対する耐性がないテストであるとし、改善が必要であるということを論じています。

単体テストとアーキテクチャ

また本書では、ソフトウェアのアーキテクチャにも論が及びます。単体テストを扱った書籍で何故アーキテクチャの話をするのでしょうか？それは、単体テストの質を向上するためには、プロダクトコードのアーキテクチャを改善しなければならないためです。

こちらもわかりやすい例をあげると、「Humble Object」の話に触れられています。これはテストを書きにくい箇所を質素（Humble）にし、テストを書きやすい部分を抜き出してテストを書きにくい箇所を包み込むようにしていく、という考え方です（いろいろな本に書かれています）。

また、特に強い印象を受けたのは、ヘキサゴナルアーキテクチャの一種として紹介された、関数型アーキテクチャという考え方です。これはアーキテクチャの中心を関数型で構成し（Functional Core）、その外側にMutable Shellを置くというものです。常に関数型アーキテクチャを採用することが正解というわけではありませんが、考え方としてはとても興味深いと思いました。

モック

また、モック主義者で触れたように、モックの使い方もひとつの論点となっています。記事にも書きましたが、このあたりの考え方についてはアップデートして行きたいと思っています。

Reference

1. Vladimir Khorikov, 須田智之（訳）, (2022), 単体テストの考え方/使い方, マイナビ出版