pytestでmockが不要になる？テストコードをシンプルにして保守性を高める設計手法

pytestでテストコードを書く際、「mockを多用しないとテストが書けない」と感じた経験はないだろうか。
外部APIやDBアクセスをモックで置き換え続ける設計は、一見するとテスト容易性を確保しているように見えるが、実際には実装詳細への依存を強め、リファクタリング耐性を下げる原因にもなり得る。
テストが壊れやすいプロジェクトほど、この「mock前提設計」に陥っているケースが多い。

本質的な解決策は、pytestの使い方ではなく、そもそもmockが必要になりにくい設計に寄せることにある。
依存を外側に追い出し、純粋なロジックと副作用を分離することで、テスト対象は自然とシンプルになる。
結果として、テストは入力と出力の検証に集中でき、過剰な差し替えは不要になる。

具体的には次のような設計アプローチが有効だ。

• 依存性注入（DI）によって外部リソースを明示的に受け取る
• 副作用を持つ処理をインフラ層へ分離する
• 純粋関数としてビジネスロジックを切り出す

これらを徹底すると、pytestで無理にmockを差し込む必要が減り、代わりに小さな関数単位でのテストが成立するようになる。

結果として得られるのは、単にテストコードが短くなることではない。変更に強く、意図が読み取りやすい設計そのものが手に入る点にある。mockを減らすことは目的ではなく、設計の健全性を取り戻すための副作用に過ぎない。“`

pytestでmockが不要になる設計とは何か

pytestでテストを書く際に「mockを減らす」「mockを不要にする」という話は、単なるテスト手法の改善ではなく、設計思想そのものの転換を意味します。
多くのプロジェクトでは外部依存（API、DB、ファイルI/Oなど）をそのまま扱うためにmockが大量に導入されますが、これはテスト容易性を後付けで確保している状態に過ぎません。

本質的にmockが不要になる設計とは、テストのために振る舞いを差し替える必要がない構造を最初から作ることです。
つまり、依存を隠蔽せず、明示的に分離し、テスト対象の責務を限定することで成立します。

まず前提として、mockが必要になる典型的な構造を整理します。

• ビジネスロジックが直接DBアクセスを呼び出す
• APIクライアントがロジック内部に埋め込まれている
• ファイルI/Oやネットワーク処理が関数内に混在している

このような構造では、テスト時に外部環境へ依存してしまうため、結果としてmockで差し替える必要が生じます。
しかしこれは「テストのために実装をねじ曲げている」状態であり、設計としては健全とは言えません。

mockが不要になる設計の中心には、依存関係の明確化があります。
特に重要なのは以下の3点です。

• 依存性をコンストラクタや関数引数で明示的に受け取る
• 副作用（I/O）と純粋な計算ロジックを分離する
• インフラ層とドメイン層を構造的に切り分ける

これにより、テスト対象は純粋なロジックへと収束し、外部依存は呼び出し側に押し出されます。

例えば以下のような設計差が典型的です。

悪い例（mockが必要になる構造）

class UserService:
    def __init__(self):
        self.db = DatabaseClient()
    def get_user_name(self, user_id):
        user = self.db.fetch(user_id)
        return user["name"]

この場合、DatabaseClientを必ずmockしなければテストできません。

改善例（mock不要に近づく構造）

def get_user_name(user_repo, user_id):
    user = user_repo.fetch(user_id)
    return user["name"]

このように依存を外部から注入するだけで、テストは単純なダミー実装で代替可能になります。
pytestではfixtureとして辞書や簡易オブジェクトを渡すだけで十分になり、mockの複雑な設定は不要になります。

さらに重要なのは、副作用の扱いです。
副作用を持つ処理が混在していると、どれだけmockを減らそうとしても限界があります。
そのため、次のような分離が有効です。

層	役割	テスト方法
ドメイン層	純粋なビジネスロジック	通常の関数テスト
アプリケーション層	ユースケース制御	ダミー依存でテスト
インフラ層	DB/API/外部I/O	統合テスト

このように責務を明確に分けることで、pytestでmockを使う必要がある範囲そのものを縮小できます。

結論として、pytestでmockを不要にする設計とは「mockを使わないテクニック」ではなく、「mockが必要になる構造を最初から作らないこと」です。
依存性の明示化と副作用の分離を徹底することで、テストは単純化され、結果として保守性の高いコードベースへと進化します。

mockが増えるテストコードの問題点と保守性の低下

mockはテストにおいて強力な手段ですが、設計方針として過度に依存すると、コードベース全体の保守性を静かに蝕む要因になります。
特にpytestのように柔軟なテストフレームワークでは、簡単にmockを追加できるため、その利便性が逆に設計の歪みを助長するケースが少なくありません。

mockが増える構造の本質的な問題は、「テストが仕様ではなく実装詳細に結びついてしまう点」にあります。
これは長期的に見ると、リファクタリング耐性の低下として顕在化します。

まず、mock依存が強いコードに共通する特徴を整理します。

• クラスや関数内部で直接外部依存を生成している
• 呼び出し順序や内部実装に対してテストが依存している
• テストコードが本体コードより複雑になっている

このような構造では、実装の小さな変更でもテストが容易に破綻します。
例えばメソッド名の変更や呼び出し順序の変更といった本来は内部改善に過ぎない変更であっても、mockの設定が壊れることでテスト全体が失敗することになります。

次に、mock過多による具体的な問題を整理すると、以下の3点が特に重要です。

1. テストの脆弱性が増大する

mockは「実際の振る舞い」ではなく「仮想的な振る舞い」を定義するため、実装と乖離が発生します。
その結果、以下のような問題が起きます。

• 本番では起きない挙動をテストが通過する
• 本番では起きる問題をテストが検知できない

これはテストの信頼性を直接的に損なう要因になります。

2. テストコードの複雑化

mockが増えるとテストコードは次第に「検証コード」ではなく「準備コード」に支配されます。
例えばpytestでよくある構造は次のようになります。

def test_example(mocker):
    mock_db = mocker.Mock()
    mock_db.fetch.return_value = {"name": "Alice"}
    mock_api = mocker.Mock()
    mock_api.call.return_value = 200
    service = Service(db=mock_db, api=mock_api)
    result = service.run(1)
    assert result == "Alice"

このように、テストの本質である「入力と出力の確認」よりも、依存オブジェクトの構築が中心になってしまいます。

3. リファクタリング耐性の低下

mockは内部実装に強く依存するため、設計変更に対して非常に敏感です。
例えば以下のような変更です。

• メソッド呼び出しを同期から非同期に変更
• サービス層の分割
• APIクライアントの差し替え

これらは本来設計改善ですが、mockを多用しているテストではすべて修正対象になります。
結果として「コードを改善するほどテストコストが増える」という逆転現象が発生します。

この問題は特に大規模プロジェクトで顕著になります。
mockの設定が数十行に及ぶテストが増えると、以下のような悪循環に陥ります。

• テスト修正が面倒になる
• テストが更新されなくなる
• 古い仕様を検証し続けるテストが残る

これは品質維持という観点では非常に危険な状態です。

重要なのは、mock自体が悪いのではなく、「mockを前提にした設計」が問題であるという点です。
適切に設計されたコードではmockは補助的な役割に留まり、主要なテスト戦略にはなりません。

つまりmockが増えることは単なるテスト技法の問題ではなく、設計の分離レベルや依存構造の設計品質を映す指標でもあります。

pytestにおけるmockの基本的な役割と使い方

pytestにおけるmockは、外部依存を切り離し、テスト対象のロジックを単体で検証するための重要な仕組みです。
特にPythonでは標準ライブラリのunittest.mockやpytest-mockプラグインを利用することで、関数やオブジェクトの振る舞いを柔軟に差し替えることができます。

mockの本質的な役割は「不安定な外部要因を制御可能な入力に変換すること」にあります。
例えばネットワーク通信やデータベースアクセスは実行環境に依存するため、そのままではテストの再現性が低くなります。
そこでmockを使い、固定されたレスポンスを返すことで、ロジックのみを純粋に検証できるようにします。

patchとMagicMockの基本構文

pytestで最も頻繁に利用されるのがpatchとMagicMockです。
patchは対象オブジェクトを一時的に差し替える仕組みであり、MagicMockはその差し替え先として振る舞いを定義するためのオブジェクトです。

以下は基本的な構文の例です。

from unittest.mock import patch, MagicMock
def fetch_data():
    return api_client.get("/data")
def test_fetch_data():
    with patch("__main__.api_client") as mock_client:
        mock_client.get = MagicMock(return_value={"value": 42})
        result = fetch_data()
        assert result == {"value": 42}

この例ではapi_clientのgetメソッドをmock化し、外部通信を完全に排除しています。
これによりテストは外部環境に依存せず安定して実行できます。

よくあるmockの誤用パターン

mockは便利である一方、使い方を誤るとテストの品質を著しく低下させる原因になります。
特に以下のようなパターンは注意が必要です。

• 実装詳細に依存したmock設定
• 過剰なreturn_valueやside_effectの複雑化
• テスト対象よりmock設定コードの方が長い状態

特に問題となるのは、内部実装の呼び出し順序まで検証してしまうケースです。
これはリファクタリング耐性を大きく損ないます。

例えば以下のようなテストは典型的な誤用です。

def test_service():
    mock_repo = MagicMock()
    mock_repo.fetch.return_value = {"id": 1}
    service = Service(mock_repo)
    service.process(1)
    mock_repo.fetch.assert_called_once_with(1)

このようなテストは「結果」ではなく「実装の呼び出し方法」を検証してしまっています。
そのため内部実装が変わると、正しい振る舞いであってもテストが失敗する可能性があります。

重要なのは、mockはあくまで「外部依存を隔離するための補助」であり、「設計を検証するための主役ではない」という点です。
pytestでは特に柔軟性が高いため、mockの使い方次第で設計品質そのものが大きく左右されます。

依存性注入でmockを減らす設計アプローチ

依存性注入（Dependency Injection, DI）は、mockを減らす設計において最も重要なアプローチの一つです。
本質的には「オブジェクトが自分で依存を生成しない」というルールに従い、必要な依存関係を外部から渡すことで、構造的にテスト容易性を高める手法です。

pytestにおいてmockが多用される根本原因の多くは、依存関係がコード内部に隠蔽されている点にあります。
DIを導入することで、この隠蔽を取り除き、テスト時には実体ではなく簡易な差し替え実装を注入できるようになります。

まず、依存性注入の有無による構造の違いを整理します。

観点	DIなし	DIあり
依存生成	クラス内部	外部から注入
テスト容易性	低い	高い
mock必要性	高い	低い
リファクタ耐性	低い	高い

この違いは単なるコーディングスタイルではなく、設計の責務分離そのものに関わります。

DIなしの典型的な問題構造は以下のようになります。

class OrderService:
    def __init__(self):
        self.repository = OrderRepository()
        self.payment = PaymentGateway()
    def checkout(self, order_id):
        order = self.repository.find(order_id)
        return self.payment.charge(order["amount"])

この構造では、OrderRepositoryやPaymentGatewayが内部で生成されているため、テスト時には必ずmockで差し替える必要が生じます。
さらに依存が増えるほどmock設定も増殖し、テストの複雑性が指数的に増加します。

一方でDIを適用すると構造は次のように変わります。

class OrderService:
    def __init__(self, repository, payment):
        self.repository = repository
        self.payment = payment
    def checkout(self, order_id):
        order = self.repository.find(order_id)
        return self.payment.charge(order["amount"])

この変更の本質は「生成責任の外部化」です。
これにより、OrderServiceは純粋にユースケースの制御のみを担当し、外部システムとの結合度が大幅に低下します。

pytestにおいては、この構造変更の効果は非常に明確に現れます。
mockを使わずとも、以下のような簡易ダミーで十分にテストが成立します。

class FakeRepository:
    def find(self, order_id):
        return {"amount": 100}
class FakePayment:
    def charge(self, amount):
        return f"charged:{amount}"
def test_checkout():
    service = OrderService(FakeRepository(), FakePayment())
    result = service.checkout(1)
    assert result == "charged:100"

このようにDIを導入すると、mockの代わりに「意図を持った軽量な実装」を使えるようになります。
これは単なるテスト簡略化ではなく、テストコードが仕様の一部として読みやすくなるという副次的効果も持ちます。

さらに重要なのは、DIによって設計が自然とレイヤー化される点です。
依存関係が明示されることで、以下のような構造的メリットが得られます。

• ビジネスロジックが純粋化される
• インフラ層の差し替えが容易になる
• テストの粒度が安定する

特に長期運用のシステムでは、この構造的安定性が保守コストに直結します。

結論として、依存性注入は単なるテスト技法ではなく、「mockを減らすための設計そのもの」です。
pytestの柔軟性に頼るのではなく、依存の流れを制御することで、テストはより単純で意味の明確なものへと変化します。

副作用を分離して純粋関数にする設計の重要性

pytestでmockを減らすための設計を突き詰めていくと、最終的に到達するのが「副作用の分離」と「純粋関数化」という考え方です。
これは単なるテスト容易性の改善ではなく、コードそのものの意味構造を整理するための基本原則でもあります。

副作用とは、関数の外部状態に影響を与える処理のことを指します。
具体的には以下のようなものです。

• ファイル書き込みや読み込み
• データベース更新
• ログ出力
• 外部API呼び出し

これらがロジック内部に混在している場合、テストは必然的にmockに依存せざるを得なくなります。
しかし副作用を分離し、純粋関数としてロジックを切り出すことで、テストは入力と出力の対応関係を確認するだけの単純な構造に変化します。

まず、副作用を含む設計と純粋関数設計の違いを整理します。

観点	副作用混在設計	純粋関数設計
テスト方法	mock必須	値の比較のみ
再現性	低い	高い
デバッグ容易性	難しい	容易
リファクタ耐性	低い	高い

この差は設計の複雑性に直結し、長期的な保守コストに大きな影響を与えます。

例えば、税計算ロジックを考えてみます。
副作用を含む設計では次のようになります。

class TaxCalculator:
    def __init__(self, logger):
        self.logger = logger
    def calculate(self, price):
        tax = price * 0.1
        self.logger.info(f"tax calculated: {tax}")
        return price + tax

この場合、テストではloggerをmock化しないと実行できず、本質的には「ログ出力の確認」がテストに混入します。

一方で、純粋関数として分離すると構造は大きく変わります。

def calculate_tax(price):
    return price * 0.1
def calculate_total(price, tax_rate_func):
    tax = tax_rate_func(price)
    return price + tax

この設計では、ロジックは完全に入力と出力の関係だけで表現されており、副作用は外部に追い出されています。
その結果、pytestでは単純な値検証だけでテストが成立します。

この設計の本質的な利点は、テスト容易性だけではありません。
むしろ重要なのは「認知負荷の低減」です。
純粋関数は状態を持たないため、以下の特徴を持ちます。

• どの入力でも結果が一定
• 実行順序に依存しない
• 外部環境に影響されない

これにより、コードを読む側は「何をしているか」だけに集中でき、「どこに影響するか」を追跡する必要がなくなります。

さらに、純粋関数化は設計全体にも波及効果を持ちます。
例えば、以下のような構造分離が自然に成立します。

• ドメイン層：純粋関数のみ
• アプリケーション層：処理の組み立て
• インフラ層：副作用の実行

この分離により、テストの役割も明確に変化します。

• ドメイン層：pytestで完全に単体テスト可能
• アプリケーション層：軽量な統合テスト
• インフラ層：限定的な結合テスト

重要なのは、副作用を「悪」と捉えることではありません。
副作用はシステムに不可欠ですが、それを「ロジックと混ぜない」という設計規律こそが本質です。
pytestにおけるmock削減も、この設計規律の結果として自然に実現されるものです。

つまり、純粋関数化とはテスト技法ではなく、設計の透明性を高めるための構造的な意思決定だと言えます。

レイヤードアーキテクチャでテスト容易性を高める

レイヤードアーキテクチャは、システムを複数の責務レイヤーに分割することで、依存関係を整理し、結果としてテスト容易性を高める設計手法です。
pytestにおいてmockを減らすという観点から見ても、この構造は非常に相性が良く、設計とテスト戦略を自然に一致させる役割を持ちます。

特に重要なのは、レイヤーごとに「責務の純度」を保つことです。
責務が混在すると、結局はmockで境界を無理に切り出す必要が生じ、設計とテストの整合性が崩れます。

まず、一般的なレイヤー構造を整理します。

• プレゼンテーション層：入力と出力の制御
• アプリケーション層：ユースケースの調整
• ドメイン層：ビジネスロジック
• インフラ層：外部システムとの接続

この分離が明確であるほど、テスト対象は自然と小さくなり、mockの必要性も減少します。

レイヤードアーキテクチャの本質的な利点は、「依存の方向が一方向に制御されること」です。
上位レイヤーは下位レイヤーに依存できますが、その逆は成立しません。
この制約により、設計は自然と安定した構造になります。

観点	フラット構造	レイヤード構造
依存関係	無秩序	一方向
テスト容易性	低い	高い
mock必要性	高い	低い
リファクタ耐性	低い	高い

具体的な問題構造を見てみます。
レイヤー分離がない場合、ビジネスロジックが直接DBやAPIに依存することが一般的です。

このような構造では、テスト時に以下の問題が発生します。

• DBアクセスのmockが必須になる
• API呼び出しの順序に依存するテストになる
• ロジック単体の検証が困難になる

結果として、テストは「振る舞いの確認」ではなく「実装の再現」になってしまいます。

一方でレイヤードアーキテクチャでは、ドメイン層を中心にロジックを純粋化できます。
例えば、注文処理を考えた場合、ドメイン層は次のように構成されます。

def calculate_discount(price, rule):
    return price * rule

このような純粋関数は外部依存を持たないため、pytestでは単純な入力と出力の比較のみでテストが完結します。

アプリケーション層は、ドメインロジックとインフラを接続する役割を持ちますが、ここでも依存は注入される形にすることでmock依存を回避できます。

class OrderAppService:
    def __init__(self, repo, payment):
        self.repo = repo
        self.payment = payment
    def execute(self, order_id):
        order = self.repo.find(order_id)
        total = order["amount"]
        return self.payment.charge(total)

この構造では、テスト時にインフラ層をダミー実装に差し替えるだけで十分であり、複雑なmock設定は不要になります。

さらに重要なのは、インフラ層を明確に切り離すことで、テスト戦略自体を分離できる点です。

• ドメイン層：単体テスト（高速・mock不要）
• アプリケーション層：軽量な統合テスト
• インフラ層：限定的な結合テスト

この分離により、pytestで全体をmockで支える必要がなくなり、テストピラミッドが自然に安定します。

レイヤードアーキテクチャの本質は単なる構造分割ではありません。
それは「依存関係の方向を設計で制御する」という思想です。
この制御が行われている限り、テストは構造的に簡素化され、mockに依存しない設計へと収束します。

結果として、pytestは複雑なmockフレームワークではなく、純粋な検証ツールとして機能するようになります。

pytestでmockなしテストを書く実践パターン

pytestでmockを使わずにテストを書くためには、単に「mockを使わない」と決めるだけでは不十分であり、設計段階から依存関係と責務を分離しておく必要があります。
特に重要なのは、テスト容易性を後付けではなく、構造として内包することです。

mockなしテストの成立条件は明確で、主に以下の3点に集約されます。

• 副作用が外部レイヤーに隔離されている
• 依存関係が注入可能である
• ドメインロジックが純粋関数として成立している

この条件が揃っていれば、pytestはmockなしでも十分に強力なテスト基盤として機能します。

まず、mockなしテストの基本的な考え方として「Fake実装の活用」があります。
これはmockのように振る舞いを細かく制御するのではなく、シンプルな代替実装を用意する方法です。

例えば、ユーザー取得処理を考えます。

class FakeUserRepository:
    def __init__(self):
        self.data = {1: {"name": "Alice"}}
    def find(self, user_id):
        return self.data.get(user_id)

このようなFakeは、外部DBの代わりとして機能しますが、mockと異なり「動作する実装」である点が重要です。
これによりテストは実装詳細ではなく振る舞いに集中できます。

次に、サービス層とFakeの組み合わせです。

class UserService:
    def __init__(self, repo):
        self.repo = repo
    def get_user_name(self, user_id):
        user = self.repo.find(user_id)
        return user["name"]

この構造に対してpytestでは以下のようにテストできます。

def test_get_user_name():
    repo = FakeUserRepository()
    service = UserService(repo)
    result = service.get_user_name(1)
    assert result == "Alice"

このテストではmockは一切使用されていませんが、依存性注入とFake実装により完全に単体テストとして成立しています。

mockなしテストを成立させるための重要な設計パターンを整理すると、次のようになります。

1. ポートとアダプタの分離

外部システムへのアクセスをインターフェースとして抽象化し、実装を差し替え可能にします。

2. ドメインロジックの純粋関数化

状態や副作用を排除し、入力と出力のみに責務を限定します。

3. Fakeによる代替実装

mockのような振る舞い指定ではなく、実際に動作する軽量実装を用意します。

特にFakeの重要性は見落とされがちですが、pytestにおいては非常に実用的です。
mockは「検証のための制御装置」ですが、Fakeは「小さな実装そのもの」であるため、テストの信頼性が高くなります。

観点	mock	Fake
実装性	なし	あり
テストの安定性	中	高
設計依存度	高い	低い
保守性	低い	高い

さらに重要なのは、mockなし設計ではテストの意図が明確になる点です。
mockを使う場合、テストコードは「どのメソッドが呼ばれたか」に焦点が移りがちですが、Fakeでは「結果が正しいか」に集中できます。

これによりテストは仕様ドキュメントとしての役割を持つようになり、コードベース全体の理解性が向上します。

結論として、pytestでmockなしテストを書くための実践パターンは、単なるテクニックではなく設計そのものの結果です。
依存の注入、純粋関数化、Fakeの導入という3つの要素が揃うことで、mockに依存しない健全なテスト体系が成立します。

mock依存設計のアンチパターンと改善方法

pytestでmockを活用すること自体は問題ではありませんが、設計がmock前提になってしまうと、コードの構造そのものが歪み、長期的な保守性を著しく損ないます。
特にPythonのように柔軟な言語では、実装の自由度が高いがゆえに、無意識のうちにmock依存設計へと傾きやすい点が注意点です。

mock依存設計の本質的な問題は、「テストのために実装が複雑化する」という逆転現象にあります。
本来であればプロダクトコードが主でテストが従であるべきですが、mock中心の設計ではテストの都合が設計を支配してしまいます。

まず、典型的なアンチパターンを整理します。

• クラス内部で依存オブジェクトを生成してしまう
• メソッド呼び出し順序をテストで厳密に検証する
• mockのreturn_valueやside_effectが複雑化する
• テストコードが本体コードより長くなる

これらの状態が揃うと、テストは仕様検証ではなく「実装再現コード」へと変質します。

特に問題となるのが、依存の隠蔽です。
例えば以下のような設計は典型的なアンチパターンです。

class PaymentService:
    def __init__(self):
        self.gateway = StripeGateway()
    def pay(self, amount):
        return self.gateway.charge(amount)

この構造ではStripeGatewayが内部で固定されているため、テストでは必ずmockで差し替える必要があります。
しかしこれは設計としては柔軟性を欠いており、変更に対して非常に脆弱です。

次に、改善方法として最も重要なのは依存性の外部化です。
依存をコンストラクタや関数引数として明示的に受け取ることで、テスト時の差し替えを容易にします。

class PaymentService:
    def __init__(self, gateway):
        self.gateway = gateway
    def pay(self, amount):
        return self.gateway.charge(amount)

この変更により、mockを使わずともFake実装や簡易オブジェクトでテストが可能になります。

さらに重要な改善アプローチとして、副作用の分離があります。
ビジネスロジックとI/O処理を混在させると、必然的にmockが増加します。

観点	mock依存設計	改善後設計
依存生成	内部生成	外部注入
テスト方法	mock前提	値ベース
保守性	低い	高い
可読性	低い	高い

もう一つの重要な改善は、テストの視点を「実装検証」から「結果検証」へ移すことです。
mock依存設計では以下のようなテストが多く見られます。

def test_payment():
    gateway = MagicMock()
    gateway.charge.return_value = "ok"
    service = PaymentService(gateway)
    service.pay(100)
    gateway.charge.assert_called_once_with(100)

このようなテストは内部呼び出しに依存しており、リファクタリングに極めて弱い構造です。

改善後は、次のように結果のみを検証する形に変わります。

class FakeGateway:
    def charge(self, amount):
        return f"charged:{amount}"
def test_payment():
    service = PaymentService(FakeGateway())
    result = service.pay(100)
    assert result == "charged:100"

この形では実装の詳細ではなく振る舞いそのものを検証できるため、テストの意図が明確になります。

結論として、mock依存設計のアンチパターンは単なるテスト手法の問題ではなく、設計そのものの責務分離の失敗です。
改善の本質はmockを減らすことではなく、mockが必要になる構造を排除することにあります。
そのためには依存性の明示化、副作用の分離、結果ベースのテスト設計という3点を一貫して適用することが重要です。

まとめ：pytestでmockに頼らない設計でテストをシンプルにする

pytestにおいてmockを減らすというテーマは、単なるテスト技法の改善ではなく、ソフトウェア設計そのものの成熟度に直結する問題です。
本記事で見てきたように、mockは適切に使えば有用なツールですが、設計がそれに依存してしまうと、テストは複雑化し、保守性は確実に低下します。

重要なのは「mockをどう使うか」ではなく、「mockが不要になる構造をどう作るか」という視点です。
この視点に立つことで、テストコードは補助的な存在から、設計の健全性を映し出す指標へと変わります。

これまでの内容を整理すると、mockに頼らない設計には共通する原則があります。

• 依存関係を内部で生成せず外部から注入する
• 副作用をドメインロジックから分離する
• 純粋関数としてロジックを構造化する
• Fake実装を用いてテストの再現性を担保する
• レイヤー分離により責務を明確化する

これらは個別のテクニックではなく、相互に補完し合う設計原則です。

特に重要なのは、テストの粒度と設計の粒度を一致させることです。
mockを多用する設計では、この粒度の不一致が頻繁に発生し、テストが実装詳細に引きずられる原因になります。
一方で、依存性注入やレイヤードアーキテクチャを適切に適用した設計では、テストは自然と「入力と出力の関係」を検証するシンプルな形に収束します。

観点	mock依存設計	mock最小設計
テストの複雑性	高い	低い
保守性	低い	高い
リファクタ耐性	低い	高い
設計の明確性	曖昧	明確

また、実務的な観点では「mockを完全に排除する」ことが目的ではありません。
重要なのは、mockの役割を限定し、設計の中心に据えないことです。
外部I/Oの境界部分ではmockやスタブは依然として有効ですが、ビジネスロジックの検証にまで持ち込む必要はありません。

最終的に到達すべき状態は、pytestが「複雑な差し替えツール」ではなく「純粋な振る舞い検証ツール」として機能している状態です。
そのためには、以下のような設計指針を継続的に意識することが重要です。

• 依存は隠さず明示する
• ロジックは純粋化する
• 副作用は外に追い出す
• テストは結果だけを見る

結論として、pytestでmockに頼らない設計とは、テストを簡単にするための小手先の工夫ではなく、コードベース全体の構造を整理するための設計哲学です。
この哲学を採用することで、テストはより単純になり、同時にシステム全体の理解性と保守性も大きく向上します。