今の時代、テストを書くのは当たり前になっているため若手もベテランも自然とテストを書くようになっているが、テストの質（メンテナンス性や実行時間 etc…）が気になりはじめていた。
例えば、endpoint単位の統合テストのようなもので、閏年などを考慮した境界値のケースをgoのtable driven testで回してる等。 閏年を考慮したロジックがとあるendpointで含まれているというのはendpointを叩く側は気にしなくていい話なので、もし何かテストを書くとしても日付によってresponse結果が変わることを確認するくらいのテストにとどめておいて、 閏年によるロジックが正しく動作するかは 別途単体テストを書いたほうがいいのでは？ みたいな話がちょこちょこ発生していた。
実行時間に関しては、許されるならマシンのスペックを上げるなりで対処できる。
しかし、可読性の担保や機能追加時のテスト改修などで他人が書いたテストに手を入れるのが大変で、どうしたものかなというお気持ちで本書を手にしたら良かったという話です。
本の紹介
単体テストの基礎だけではなく、「テストを書きましょう」から次の段階である 「テストの作成に費やした労力が価値として最大限に引き出せる単体テストを作成できる」 ようになることについて知識を身に付けられるようにするのが本書の目的。
単体テストとは何か？を改めて説明しつつ、ベスト・プラクティスとよく目にするアンチ・パターンについて紹介している。
本書を読み終わると、テストを用いて、保守がしやすく、かつ変更もしやすいソフトウェアを提供できるための知識を身につけることができる。
読んだ感想
改めて単体テストや統合テストなどについて考える機会になった。
あ〜これこれという感じで、最近の自分が単体テストを書く/読むときに、試行錯誤した結果たどり着いたのがアンチパターンを回避しようとしてたのかということを実感した。
第2部の第4章にある「良い単体テストを構成する4本の柱」の部分で書かれていた、保守のしやすさを除く以下3つの柱は密接な関係があり、すべて最大限に備えた理想的な単体テストを作成することは不可能という話が特に自分が興味ある話だったと思う。
- リファクタリングへの耐性
- 退行に対する保護
- 迅速なフィードバック
本書では基本的に リファクタリングへの耐性と保守のしやすさを最大限 にしつつ、退行に対する保護と迅速なフィードバックのバランス調整を行う とよいと書かれていて、今までこの辺りが自分の中でふわっと感覚としてはあったが、それが定義されてたのが良かった。
あとは、第10章のデータベースに対するテストに関してだが、テストの肥大化やテストの並行実行などでデータベースがボトルネックになってテストの実行時間が遅くなるという問題があると思っていて（金で殴ればなんとかなる話でもあることもある）そこに関してどうするべきなのかが、特に言及されておらず次の段階の課題という感じがした。
テストを書くのが当たり前になってきたが、「最近実装の5〜10倍くらいテスト書くのに時間かかってるな…」とか「機能追加時のテストケース追加や改修が難しすぎてテストを投げ捨てたくなった」とか思ってる人にはオススメの本です。