良いテストの判断とは——『単体テストの考え方・使い方』第2部を読んでまとめてみた

はじめに

こんにちは。株式会社アイスリーデザインの芹田です。

第1部では、「なぜ単体テストをするのか」「単体とは何か」「読みやすいテストの型」を整理しました。

▼リリース前は気が重い——『単体テストの考え方・使い方』第1部を読んでまとめてみた
https://tech.i3design.jp/unit-testing-guide-part1/

次は、「このテストは、良いの？悪いの？」という疑問にぶつかります。

網羅率でも本数でもなく、判断できる物差しが欲しい。そこを深掘りしてくれるのが第2部です。

本記事は、その読書メモの第2部を、次の流れで自分なりに噛み砕いてまとめたものです。
物差し → モックで検証する相手 → 検証の手法 → 投資先の選び方

理解しやすいよう言い換えた箇所もあるため、厳密な用語とは異なる表現があるかもしれませんが、同じように「良い／悪い」の判断軸が欲しい方のきっかけになれば幸いです。

物差し〜良いテストを構成する4本の柱〜

第4章の核心は、「良いテスト」を感覚ではなく、4つの観点で語ることです。

柱	現場で言うと
リグレッション（デグレ）への保護	バグをどれだけ検出できるか
リファクタリング耐性	設計を直しても、テストが誤って落ちないか
迅速なフィードバック	テストがどれだけ速く返ってくるか
保守のしやすさ	読んで・直して・実行するのが楽か

「リグレッションへの保護」は、第1部で「リグレッション（デグレ）防止」と書いた価値と同じ観点です。ここでは第4章の柱名に合わせて「保護」と表記します。

本書では、「4本のうち1つでも欠けているテストには価値がない」と言っています。（正直、ここはかなり厳しい基準だと感じました…）
言い換えると、テストの価値は4つの掛け算のような関係で、どれかがゼロなら全体もゼロ、という考え方です。完璧である必要はありませんが、ゼロの柱を残さない、という意味だと理解しました。

一方、リグレッションへの保護・リファクタリング耐性・迅速なフィードバックの3つは、1本のテストで同時に最大化できません。
だからこそ、テストの種類ごとに役割を分ける「テストピラミッド」の考え方が成り立ちます。単体は速く狭い範囲を守り、E2E は広く遅い、といった分担です。

モック〜検証対象を間違えると壊れる〜

第5章では、前章の4本柱の観点から、モックの使い方を見ます。

モックが壊れやすくなるのは、道具そのものが悪いからではありません。「どの相手とのやりとりを検証するか」という対象選びを誤ることが原因です。

たとえば「注文を確定したら、確認メールを送る」という機能を想像してください。

	適切な対象（外部との約束）	不適切な対象（内部の実装詳細）
検証内容	「確認メールを送る」という外部への約束が守られたか	注文クラスが、内部の別クラスのメソッドをこの順番で呼んだか
なぜそう言えるか	アプリの外（メールサービス）とのやりとりだから	アプリの中のクラス同士のやりとりだから
モックで見てよいか	よい（「送られたか」を見てよい）	よくない（設計を直すたびに呼び出し順が変わり、テストだけが落ちやすい）

前者はビジネス上の約束（観察可能な振る舞い）です。後者は実装の詳細です。第4章の「リファクタリング耐性」を自分で壊してしまうのが、後者のパターンです。

書籍では、この違いを次の2つに分けています。

種類	何か	モックで検証してよいか
システム間コミュニケーション	アプリと外部（メール、決済、他サービス）とのやりとり	よい（外から見える約束）
システム内コミュニケーション	アプリ内のクラス同士のやりとり	よくない（実装の詳細）

ここでいう「よい」は、外部サービスの内部実装まで縛る話ではありません。アプリが外部に対して持つ契約のうち、観察できる最小限を検証する、という意味です。

あわせて、置き換えたあとの「検証する／しない」も押さえておきます。コマンド／クエリは操作の分類、モック／スタブは置き換える道具の分類です。

	テストダブル	扱い
状態を変える・起こす操作（コマンド）	モック	呼ばれたか・契約に必要な範囲でどう呼ばれたかを検証する
データを返すだけの操作（クエリ）	スタブ	値を返すだけ。呼び出しは検証しない

コマンドは「何かを変える・起こす操作」、クエリは「データを返すだけの操作」です。スタブは、テスト条件を作るために値を返す置き換えなので、「スタブが呼ばれたか」まで検証してはいけません。

まとめると、

モックは外部との境界で使うこと。
クラス同士の内部の呼び方まではモックで縛らないこと。
スタブとのやりとりは検証しないこと。

ということでした。

第1部で「共有依存だけをテストダブルに置き換える」と整理した方針が、ここで「どこを検証するか」まで具体的になってきます。

手法〜何を見て「成功」と判定するか〜

第6章では、検証の仕方が3つに整理されます。

手法	何を検証するか
出力値ベーステスト	返ってくる値
状態ベーステスト	実行後に残る状態
コミュニケーションベーステスト	他オブジェクトとのやりとり

（本書でいう「古典学派」は、第1部で触れた「単体＝1つの振る舞い」と捉え、共有依存だけをテストダブルに置き換える立場のことです。）

古典学派の考え方では、デフォルトの優先順位として「出力値ベース＞状態ベース＞コミュニケーションベース」と整理されています。これは「状態ベースは禁止」という意味ではなく、選べるなら出力を優先する、という話です。

注意点はシンプルです。

状態ベースでは、プライベートな状態を公開してまで検証しない
コミュニケーションベースは、アプリの境界を超え、外部から確認できる副作用があるときに限る

第5章の「境界だけモックする」と、ここで1本につながります。

正直なところ、第6章は技術寄りの話が多く、私にとっては難しく感じた箇所もありました。それでも、「何をもって成功と言えるのか」を3つに分けて考えるだけでも、既存テストの見直しには十分使えそうだと思いました。

投資先〜単体テストをどこに寄せるべきか〜

物差し・検証する相手・手法が揃っても、「どこに書くか」がずれると、テストは増えても価値は上がりません。第7章の主題はここです。

コードは、次の2軸で4種類に分けられます。

コードの複雑さ／ドメインにおける重要性
協力者オブジェクトの数（テスト対象が依存している他のクラスやモジュールの数）

種類	複雑さ／ドメイン重要性	協力者オブジェクト	単体テストの扱い
ドメインモデル／アルゴリズム	高い	少ない	いちばん価値が高い。寄せる本命
コントローラ	低め	多い	単体より統合寄り
過度に複雑なコード	高い	多い	リファクタリング対象（ロジックと難しい依存を分ける）
取るに足らないコード	低め	少ない	優先度は低い。書かない選択もあり

単体テストの価値が最も高いのは、複雑またはドメインで重要なコードです。
本書では、次の方針を推奨していました。

ドメインで重要なコードに協力者をたくさん含めない。
複雑さや重要性が上がるほど、協力者の数を減らす。

もう1つの核心は、第1部の落とし穴①と地続きです。

質の悪いテストを作るくらいなら、その種のテストは全く作らない方がよい。

「書かない」は放棄ではなく、価値の低いテストを無理に増やさない、という意味で、負債になるものは増やさないほうが良いということです。

第7章も設計の話が深く難解でしたが、「単体テストは全部に均等に書くものではない」という点は、しっかりと理解できました。

第2部の学び

章	学び
第4章物差し	4本柱で良い／悪いを語る。
第5章モック	境界だけモック。内部は縛らない。
第6章手法	出力を優先。やりとりの検証は境界外に限る。
第7章投資先	ドメイン／アルゴリズムに寄せる。悪いテストなら書かない。

第1部の「振る舞い単位・共有依存のみテストダブル化」は、第2部を読み終えた時点でも維持できる、というのが私の現時点の考えです。