ソフトウェアエンジニアリングにおける「テスト」の世界は用語が多岐にわたります。「結合テスト」「システムテスト」といっても、チームによって定義がバラバラ…なんてことはありませんか？
実際、私もそうでした。「結合テストって具体的にどこまでやるの？」「システムテストとの境界線は？」と、常に曖昧さを抱えていました。
そんな中、t-wadaさんの講演などを通じて、Googleが提唱する「Small / Medium / Large」というテストサイズの分類を知り、テストピラミッドの考え方に触れました。
開発生産性の観点から考える自動テスト（2024/06版）| Takuto Wada
「なるほど、これなら明確だ！」と感心したものの、いざ実装しようとすると新たな疑問が湧いてきました。
- 「Smallテストって、結局どういう意味でSmallなの？（クラスの数？行数？）」
- 「モック（Mock）って、いつ・どこで・どれくらい使えばいいの？」
今回は、過去の私と同じような疑問を持つ方に向けて、自分の理解の整理も兼ねて、 Googleのソフトウェアエンジニアリング におけるテスト概説の章をまとめてみます。
1. 「規模（Size）」はクラスの数ではない
まず、最も重要な概念の整理から始めましょう。Googleのテスト戦略では、以下の2つの軸を明確に区別しています。
- 範囲（Scope）： どのくらいの量のコードを検証するか（メソッド単体か、機能全体か）
- 規模（Size）： 実行にどれくらいのリソース（時間・場所・環境）を使うか
Googleが「Small / Medium / Large」で区別しているのは、後者の 「規模（Size）」 です。
クラスの数ではなく、「テスト実行時にどこまで遠くへお使いに行くか（リソースの消費量）」 で決まります。
2. テスト規模（Size）の3分類：Small, Medium, Large
技術的な定義をざっくりまとめると以下のようになります。
🐭 Small テスト（最も制約が大きい＝最重要）
「単一のプロセス内で完結すること」 が絶対条件です。
テストの遅さや「Flaky（不安定さ）」の原因となる要素を徹底的に排除します。
- 禁止事項: サーバーへの接続、DBアクセス、ディスクI/O、Sleep処理
- メリット: 爆速で動き、何度やっても必ず同じ結果になる（決定性が高い）
- Googleの教え: スコープの大小に関わらず、可能な限りSmallテストを書くよう努めること
🐈 Medium テスト
単一マシン内であれば、複数プロセスにまたがることが許されます。
- できること: 実際のデータベースインスタンスの起動、localhost内でのWeb UIとサーバーの通信
- 注意点: 柔軟性が増す分、Smallテストより遅くなり、不安定になるリスクが生じます
🐘 Large テスト
制約がなく、ネットワーク越しに複数マシンへアクセスできます。
- 用途: 本番に近い環境での設定検証、E2Eテスト（本物のオブジェクトを用いて一連のやりとりを検証する）
- デメリット: 非常に遅く、非決定性（ネットワーク遅延などでたまに落ちる）が高い。これをバグ発見の主力にしてはいけません
⚠️ 信頼不能テスト（Flaky Test）の恐怖
テストの信頼性が1%でも損なわれる（たまに失敗する）と、エンジニアはテスト結果を無視し始め、テスト全体の価値が失われます。Largeテストはこの温床になりやすいです。
3. 直感で理解する「オフィスワーク」の例え
「プロセス」や「スレッド」と言われてもピンとこない…という場合は、テストプログラムを 「わたし（作業者）」 だと想像してみてください。
Small / Medium / Large の違いは、仕事をするために、どこまで移動していいか のルールで決まります。
🐭 Small テスト ＝ 「自分のデスクだけで完結する仕事」
- ルール： 席を立ってはいけません。自分の頭と、手の届く範囲のメモ帳や電卓だけで仕事をします
-
ここが重要：
- 電卓や参考書（＝別のクラス）を使ってもOK！
- ただし、誰かと会話したり、倉庫へ資料を取りに行ったり（＝データベースやネットワーク通信）してはいけません
- 特徴： 誰にも邪魔されないので爆速で、何度やっても必ず同じ結果が出ます
🐈 Medium テスト ＝ 「同じオフィス内の同僚と連携する仕事」
- ルール： 社内（自分のパソコン）の中なら移動してOKです
-
ここが重要：
- 隣の席の「データベースさん」にデータを保存してもらう
- 同じ部屋の「Webサーバー係」に書類を渡す
- ただし、 社外（＝インターネットの向こう側）に電話してはいけません
- 特徴： 同僚がトイレに行っているかもしれません（待ち時間）。Smallより少し遅く、たまに連携ミスが起きます
🐘 Large テスト ＝ 「社外の取引先と連携する仕事」
- ルール： どこへ連絡しても、海外へ行ってもOKです
-
ここが重要：
- 実際にインターネットを通じて、外部のAPIを叩く
- ユーザーと同じようにブラウザを立ち上げて操作する
- 特徴： 電車が遅延したり、電話が繋がらなかったり（＝ネットワーク障害）します。非常に遅く、失敗しやすいです
（Geminiにて生成）
4. モック（Mock）はどう使い分ける？
テスト規模が大きくなるにつれて、「モック（偽物）の使用率は下がり、リアリティ（本物）の使用率が上がる」 というのが鉄則です。
| 観点 | Small テスト 🐭 | Medium テスト 🐈 | Large テスト 🐘 |
|---|---|---|---|
| モックの方針 |
フル活用 (すべてのI/Oを遮断) |
境界のみモック (外部接続だけ遮断) |
原則禁止 (本物を使う) |
| データベース |
モックする (インメモリなどで代用) |
本物を使う (ローカルのDocker等) |
本物を使う (実際のDBサーバー) |
| 外部API |
モックする (通信処理を差し替える) |
フェイクを使う (ローカルに偽サーバーを立てる) |
本物を使う (実際に通信する) |
🐭 Smallでのモック：「電話の模型」
Smallテストは「席を立ってはいけない」ルールなので、電話（通信）や倉庫（DB）は使えません。
そこで、電話機の模型（モック） を置いて、「電話したつもり」で仕事を進めます。
- 目的： スピードと安定性の確保
🐈 Mediumでのモック：「内線通話」
同じ部屋の同僚（ローカルDB）とは直接話します（本物を使います）。
しかし、社外への電話は禁止なので、外部APIへの接続部分だけは 偽のサーバー（フェイク） などにつなぎ変えます。
- 目的： 外部要因の排除と、内部連携の確認
🐘 Largeでのモック：「現実の通話」
実際に社外へ電話をかけます。モックは原則使いません。
ただし、「クレジットカードの課金」など危険な操作に限り、慎重にテストモード等を利用します。
- 目的： 現実世界での動作確認
5. Smallテスト判定リスト
今書いているテストが Small かどうか迷ったときに使えるチェックリストを作ってみました。
| 質問 | YESなら... | NOなら... |
|---|---|---|
| LANケーブルを抜いてもテストは成功するか？ | Small の可能性大 | Medium か Large |
| PC内のデータベース（PostgreSQLなど）を停止したら失敗するか？ | Medium | Small |
コードに sleep(1秒待つ) が入っているか？ |
Medium か Large | Small |
| テスト内でファイルを読み書きしているか？ | Medium | Small |
まとめ
Googleが推奨する理想の比率は、Small: 80%, Medium: 15%, Large: 5% です。
開発スピードを上げるコツは、「できるだけデスク（メモリ）の上だけで仕事を終わらせる（Smallテストにする）」 こと。
そのために、DBや通信が必要な部分は「モック」を使って切り離し、ロジック部分だけを高速にテストしましょう。
テストの「範囲」だけでなく「規模（お使いの距離）」を意識して、より速く、信頼性の高いテストコードを書けるようにしていこうと思います！