リリース前は気が重い——『単体テストの考え方・使い方』第1部を読んでまとめてみた

はじめに

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

チームメンバーと話していると、こんな声掛けがあります。

「単体テストは、ちゃんと書いてますか？」

もちろん、書いています。CI でも回っています。
それでも、リリース前は気が重い。そんな状態に、心当たりはないでしょうか。

私はその不安感を解消するために、Vladimir Khorikov 著『単体テストの考え方・使い方』を読み、適切な単体テストが実装されているか判断できるようにしたいと考えました。

本記事は、その読書メモの第1部を、私自身が単体テストを深く知るために、私なりに噛み砕いてまとめたものです。

私が理解しやすい言葉に変更している箇所もあるため、事実と異なって見える箇所があるかもしれませんが、私のように「単体テスト」とは何かを改めて理解したいと感じている方のきっかけになれれば幸いです。

単体テストは、何のために書くのか？

「テストはあるのに、変更が怖い」という不安に対して、第1章は次の整理を示してくれています。

単体テストは、うまく設計すれば「資産」になるが、雑に増やせば「負債」にさえなること。
目的は、機能を足し続けても品質を保てること、プロジェクトの成長を止めないこと。

単体テストの価値

第1章では、次の3つに整理されています。

価値	現場で言うと
リグレッション（デグレ）防止	直したつもりが別のところを壊した、を自動で検知できる
リファクタリング	設計を直すときの「大丈夫かな…」が減る
生きた仕様書	「この機能、何をする想定？」がテストコードで確認できる

本当に必要最小限まで削ぎ落としたまとめ方をしてくれているので、シンプルで理解しやすかったです。

知っておくべき2つの落とし穴

ここまで読むと「じゃあたくさん書いて網羅すればいい」と思いがちです。（実際、私も近い思考になっていました…）
しかし、そこを下記2つの観点ではっきり止めています。

【落とし穴①：質の低いテストは、書いても書かなくても大差ない】

場合によっては、書かない方がマシなことすらあります。コストは最初の実装だけではなく、変更のたびの修正、誤検知の調査、実行時間の増加も含めて考える必要があります。

【落とし穴②：網羅率は「合格証」にならない】

何をテストしたいかがずれたまま指標だけを追うと、カバレッジは上がるのに価値は上がりません。網羅率は、テストが足りないときの「警告灯」にはなり得ますが、品質の「合格証」にはなりません。

では「良いテスト」とは？

私が期待したのは、明確に良し悪しを決めることができる指標を使って判断することでしたが、残念ながらテストの良し悪しを自動で点数化する方法はないようです。

しかし、落とし穴を避けたうえで、著者が挙げる良いテストスイートの条件は次の3つと表現していました。

テストが開発の流れの中で回っている（CI など）
大事なロジックやビジネスルールに絞って書かれている
保守コスト最小・価値最大のバランスが取れている

さらに、数字がきれいでも変更が楽にならないなら、スイートの設計を見直すサインである可能性が高いこと。網羅率とテストの質は別物として考えること。どちらも「たしかに！」と納得できる詳細が書かれていました。

「1クラス＝1テスト」は、いつ正解になるのか？

第2章で、いよいよ「単体テストとは何か」の定義に入ります。

「1クラスにつき1テスト」——これは、正しいのでしょうか。実は学派によって、答えが変わるようです。

まず、単体テストが満たすべき条件は次の3つです。

1つの振る舞いを検証していること
実行時間が短いこと
他のテストケースから隔離されていること

ロンドン学派は「単体＝1つのクラス」と捉え、不変依存を除く依存はすべてテストダブルに置き換える考え方です。一方、古典学派は「単体＝1つの振る舞い」と捉え、共有依存（DB・ファイル・外部 API など）に限りテストダブルに置き換える考え方です。

観点	ロンドン学派	古典学派
「単体」が指すもの	1つのクラス	1つの振る舞い
テストダブルに置き換える対象	不変依存を除くすべて	共有依存のみ
隔離の考え方	クラス単位で依存を差し替える	テスト対象を共有依存から切り離す

ロンドン学派のやり方は、境界がわかりやすい反面、テストがクラスの内部実装の話に寄り、振る舞いの「物語」が見えにくくなることがあります。
古典学派は、依存が複雑なクラスのテストは大変ですが、それ自体が設計上の問題のサインになる、とも書かれています。

当社の既存プロジェクトをいくつか見てみたところ、プロジェクトによって多少の違いはあるものの、おおむね古典学派に沿った実装が多かったです。
第1部を読み終えた時点では、私も古典学派の考え方に賛成する立場です。
振る舞い単位で切り、共有依存だけをテストダブルに置き換える。この方針が、私たちの実態とも合っていると感じました。

また、実行順序によって結果が変わってしまう、あるいはテスト実行後に DB やファイルを削除する「後始末」が必要になる単体テストは、見直す価値がありそうです。

第2章では、テストの骨格として「AAA パターン」（Arrange＝準備、Act＝実行、Assert＝確認）も紹介されます。第3章では、この書き方をさらに掘り下げていきます。