概要

TDDにおいて「モック」は、
外部依存や副作用を分離し、純粋な設計を支える道具として強力に機能する。

しかし一方で、過剰なモックはテストを壊れやすく、設計を不自然にする。

本稿では、C# + xUnit + Moq による実装例を通じて、
**「モックを使うべきとき」「使ってはいけないとき」**の判断基準と、設計への影響を明確にしていく。

1. モックの目的は「外部依存の隔離」

テスト対象を純粋なロジックに保つには、外部との通信（DB/API/メール/時間など）を排除する必要がある。

public interface IClock {
    DateTime Now { get; }
}

public class GreetingService {
    private readonly IClock _clock;

    public GreetingService(IClock clock) {
        _clock = clock;
    }

    public string Greet() {
        return _clock.Now.Hour < 12 ? "Good morning" : "Good evening";
    }
}

✅ 時間に依存せず、コアロジックのテストが可能な設計

2. Moqでのモック作成とTDDでの利用

public class GreetingServiceTest {
    [Fact]
    public void Greet_BeforeNoon_ReturnsGoodMorning() {
        var clock = new Mock<IClock>();
        clock.Setup(c => c.Now).Returns(new DateTime(2024, 4, 2, 9, 0, 0));

        var service = new GreetingService(clock.Object);
        var result = service.Greet();

        Assert.Equal("Good morning", result);
    }
}

✅ モックは「対象が依存している振る舞い」の予測可能な置換である
✅ 「結果が時間に依存しない」という仕様の検証が可能になる

3. モックを使うべきタイミング

タイミング	理由
外部I/Oが関わる	実行速度・安定性・副作用防止
状態や出力が予測しにくい	時間・乱数・非同期など
フローを確認したい（コールされたか）	verify系を使って振る舞いを検証したい時
契約に従っているか検証したい	interfaceの利用側の正しさを担保

4. モックを使ってはいけない場面

状況	なぜNGか
単純なデータ構造だけの依存	モックよりフェイクや直接生成の方が自然
テスト対象の内部実装に依存する	実装の詳細に依存しすぎてテストが脆くなる
コール順、回数などを過剰に縛る	振る舞いを固定化し、リファクタに弱くなる
「なんでもモック」でテストを書く	テストが信頼できるドキュメントでなくなる

5. モックとスタブ・フェイクの選定戦略

手法	用途	特徴
モック	コールされたことを検証	`Verify()`で振る舞いを確認
スタブ	特定の戻り値を返す	振る舞いのシミュレーション
フェイク	簡易実装で依存を代替	実装あり。シンプルなテストDBなど

選定基準は「どの設計レイヤを検証したいか」

設計判断フロー

① テスト対象が外部に依存しているか？ → YES → モック/スタブを検討

② 検証したいのは戻り値か？呼び出しか？ → 値 = スタブ、呼び出し = モック

③ 依存のインターフェースがあるか？ → NO → 設計見直し（DIへ）

④ モックを導入することでテストが壊れやすくならないか？ → YES → 他の手段を検討

よくあるミスと対策

❌ あらゆる依存に対して機械的にモックを適用

→ ✅ **テストの目的が曖昧になる。**構造と責務を見直すべきシグナル

❌ モックの戻り値や呼び出し順にテストが過剰に依存

→ ✅ 振る舞いを過度に縛ると設計が変えられなくなる

❌ モックが肥大化してメンテ不能に

→ ✅ フェイクや実装差し替え可能な構造を優先する

結語

モックはTDDの中で最も誤用されやすい道具だ。
しかし本質的には、**“テストの正確性を保ちつつ、構造の透明性を確保するための隔離戦略”**である。

依存を分離することで、テストは高速・安定・意図的になる
過剰なモックは、テストを壊れやすくし、設計を硬直させる
モックは「使うこと」が目的ではない。「構造を制御する」ためにある

TDDとは、
“正しい隔離によって、誤差を制御し、構造を純化するための戦略的な設計運用である。”