『単体テストの考え方/使い方』を読んだので、感想をまとめてみる

こま（エンジニア）

2023.10.04

概要

『単体テストの考え方/使い方』を読んだので、感想をまとめてみます。

要約

良い単体テストを書くための考え方が学べる良書
400ページに文字がたっぷり詰まっているので、目次などに書かれた内容が知りたくなってきたころにじっくり読むと良いかも
解説が難解なところもあるので、章や節ごとに立ち止まって自分の言葉で嚙み砕きながら読み進めた方が良いと感じた

前置き

どんな本か

単体テストの定義を入り口とし、どうやったら良い単体テストが書けるのか丁寧に解説しています。

良い単体テストとは何かをしっかりと議論しているので、最初の章から順に読んでいけば多くの知識が得られます。
具体的には、既存の実装やテストコードをどう変更していけば良いテストコードに改善できるのか、本を読む前よりも明瞭に考えられるようになることが期待できます。

なぜ読んだか

業務や趣味でもテストコードを少しずつ書くようになりました。
テスティングフレームワークの簡単な使い方に慣れてきたことで、単純な機能であればなんとかテストコードも書けるようになってきたと感じていました。

しかし、一方でまだまだ分からないことも多いと思っていました。
例えば、メール送信など外部連携が必要な機能は、どう実装するとテストが書きやすくなるのか・テストを書くときにどこまでモックに置き換えるべきか・既存の実装にあとからテストを書きたいとき、何から始めれば良いのかなどなど、悩みの種もたくさんあります。

そんなとき、良い単体テストについて解説している本書を見つけました。
今抱えている悩みを解消し、テストコードを書くときの思考をさらに深められると期待しながら、読み進めていくことにしました。

本の構成

本の目次

第1部: 単体（unit）テストとは？
第1章: なぜ、単体テストを行うのか？
第1章: 単体テストとは何か？
第3章: 単体テストの構造的解析
第2部: 単体テストとその価値
第4章: 良い単体テストを構成する4本の柱
第5章: モックの利用とテストの壊れやすさ
第6章: 単体テストの3つの手法
第7章: 単体テストの価値を高めるリファクタリング
第3部: 統合（integration）テスト
第8章: なぜ、統合（integration）テストを行うのか？
第9章: モックのベスト・プラクティス
第10章: データベースに対するテスト
第4部: 単体テストのアンチ・パターン
第11章: 単体テストのアンチ・パターン

構成

最初に、第1部で本を通じて議論していくテーマである単体テストとはどのようなものであるか、定義を明確にします。
そして、本の肝とも言える「良い単体テストとは何か、どうすれば良い単体テストを書けるのか」について第2部で論じていきます。
第3部はもう少し視野を広げ、統合テスト(実務で見ると結合テストぐらいの範囲)で複数のモジュールを扱う場合、どうやってテストコードを書いていくのか見ていきます。

そして、第4部では単体テストを書くときのアンチパターンを補足として紹介しています。

余談ではありますが、2章の前半は理論が多めになっており、読むのに少し苦戦しました。
2章後半ぐらいから楽しくなってきたと感じたので、2章前半は流し読み程度に目を通し、後で戻ってくるような読み方でもよいかもしれないです。

読み方

いつ読むか

テスティングフレームワークの使い方は分かってきたけれど、自信を持ってテストコードを書けていないかも、と感じたときに読むと得るものがあるかもしれません。

また、400ページほどで文章がびっしりと詰まっているので、じっくり時間をかけて読むことになります。
実際に読み終わるのには、10時間以上かかりました。

ですので、最後まで読んでいくには強いモチベーションが必要です。
「はじめに」や詳細な目次に目を通してみて「知りたい内容だ！」と思ったときに読むと、折れずに楽しく読んでいけると感じました。

どう読むか

著者と議論し、考えをまとめていくように読み進めていくと、テストコードを書くときの判断材料がたくさん得られると思いました。

本を通して、いつモックを使うべきか・データベースの関わるテストはどう書くかなど、テストに関わる指針を背景を含めて丁寧に解説してくれています。
とは言え、紙面の制約もあることから論理展開が早いところもあるので、ざっくり眺めただけではすぐには理解できないところもありました。

議論しながら読む

よって、著者はどういう前提のもと、このような主張をしたのか・その主張は身近なプロジェクトに適用できそうか、著者と議論するイメージで読むよう意識すると良いかなと思いました。

例えば、書籍の中では「モックに置き換えるべきなのは管理下に無い依存である」と主張されていました。
具体例も豊富に書かれてはいますが、管理下に無い依存をモックに置き換えようという考えでは、抽象的すぎて実際のプロジェクトに適用するのは難しそうです。

経験してきたプロジェクトなどに基づき、こういう場合はモックに置き換えるべきか、もしモックに置き換えるとテストコードにどういう影響が及ぶのか整理していきます。
考えを重ねていくことで、自分なりにどういうときにモックに置き換えると良さそうか、指針を確立することを目指します。

このように章や節など、理解が浅いと思ったところで都度立ち止まって議論を深めながら読んでいきたいです。

議論することで得られるもの

こうして書き出すと中々難しそうです。

ですが、著者の考えを取り入れつつ自分なりの設計方針を確立できれば、テストコードを書くときの思考も深まってきます。
思考が深まると、「ここでの振る舞いは...だからこういう単位でテストコードを書こう」・「既存の実装に後から追加するこのテストコードは、リファクタリングの土台として退行を防ぐのを目的とする」といったように、テストコードを書くときの設計を明確な言葉で表現できるようになります。

言語化できるようになると、システムやプロジェクトが変わっても適用できるような、普遍的なテストコードの考え方が身につけられるはずです。