【Python】テストにおける「過剰なモック」というアンチパターン：なぜ内部コンポーネントをモックしてはいけないのか？

2025年10月16日

「モック（Mock）」は、テストを外部APIやデータベースといった、我々がコントロールできない要素から隔離するための非常に強力なツールです。しかし、その強力さゆえに、本来モックすべきでないものまでモック化してしまう**「過剰なモック（Excessive Mocking）」**というアンチパターンに陥ることがあります。

特に、自作の内部コンポーネント（Formやサービスクラスなど） までもモックで置き換えてしまうと、テストは本来の価値を失い、リファクタリングを妨げる「脆いテスト」になってしまいます。

今回は、「何をモックし、何をモックすべきでないか」という境界線と、内部コンポーネント間の連携をテストするための正しいアプローチについて解説します。

問題点：実装に密結合した「脆い」テスト

あるレビューサイトで、指定された星評価以上のレビューだけをフィルタリングして表示するビューを考えてみましょう。このビューは、ReviewFilterFormを使って入力値を検証し、filter_reviewsサービス関数を使って実際のフィルタリングを行います。

過剰にモックを使った、悪いテストの例:

# tests/test_views.py
from unittest import mock
from django.test import TestCase

class TestReviewListView(TestCase):
    # ビューが内部で使っているFormとサービス関数を両方モック化
    @mock.patch("reviews.views.filter_reviews")
    @mock.patch("reviews.views.ReviewFilterForm")
    def test_search_with_excessive_mocks(self, mock_form_class, mock_filter_func):
        # Arrange: モックの振る舞いを細かく設定
        mock_form_instance = mock_form_class.return_value
        mock_form_instance.is_valid.return_value = True
        mock_form_instance.cleaned_data = {"min_stars": 4}
        mock_filter_func.return_value = ["素晴らしい製品です！"]

        # Act
        response = self.client.get("/reviews/", data={"min_stars": 4})

        # Assert: ビューがモックを「正しく呼び出したか」だけを検証
        mock_form_class.assert_called_with({"min_stars": 4})
        mock_filter_func.assert_called_with(min_stars=4)
        self.assertContains(response, "素晴らしい製品です！")

このテストは成功しますが、ほとんど価値がありません。なぜなら、このテストが検証しているのは、「ReviewFilterFormとfilter_reviewsが、ビューから特定の引数で呼び出されること」だけであり、「フォームとフィルター機能が連携して、実際にレビューを正しく絞り込めるか」という本来の機能については一切検証していないからです。

このテストは、ビューの実装の詳細に強く依存（密結合）しています。もし将来、filter_reviews関数の名前をsearch_reviews_by_ratingに変更するリファクタリングを行っただけで、このテストは即座に壊れてしまいます。ユーザーから見た機能は何も変わっていないにも関わらず、です。

解決策：内部コンポーネントの連携は「統合テスト」で検証する

自分が作成したコンポーネント（ビュー、フォーム、サービスなど）が、互いに正しく連携して機能するかを検証したい場合、それらをモックで置き換えるべきではありません。代わりに、テストデータベースとテストクライアントを使い、一連の 흐름 を通してテストする**「統合テスト（Integration Test）」**を書くべきです。

モックを使わない、良い統合テストの例:

# tests/test_views.py
from django.test import TestCase
from .factories import ReviewFactory

class TestReviewListView(TestCase):
    def test_search_integration(self):
        # Arrange: テストデータベースに「本物の」データを作成
        review_to_find = ReviewFactory(stars=5, content="最高の製品です！")
        review_to_ignore = ReviewFactory(stars=3, content="まあまあでした。")

        # Act: 実際にビューのエンドポイントにリクエストを送る
        response = self.client.get("/reviews/", data={"min_stars": 4})

        # Assert: 最終的なHTMLの出力結果（ユーザーが見るもの）を検証
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, "最高の製品です！")
        self.assertNotContains(response, "まあまあでした。")

このテストは、ReviewFilterFormやfilter_reviewsの存在を直接は知りません。ただ、GET /reviews/?min_stars=4というリクエストを送ったら、最終的にどのようなHTMLが返ってくるべきか、というユーザーから見た振る舞いを検証しています。

このアプローチの利点は絶大です。

実際の振る舞いをテスト: ビュー、フォーム、サービス、モデル、テンプレートがすべて連携した、現実の機能性を検証します。
リファクタリングへの耐性: ビューの内部実装をどのように変更しても、エンドポイントの振る舞いが変わらない限り、このテストは成功し続けます。これにより、安心して内部コードの改善に取り組めます。
高い信頼性: このテストが成功すれば、「星4以上で絞り込む機能は、ユーザー視点で正しく動作している」という強い自信を得られます。