Mock / Stub / Fake / Spy — Test Double 完整指南

「我們的 test 都用 mock」聽起來合理、實際上多數人把 Mock / Stub 混為一談、亂用一通。這篇用 Martin Fowler 的標準分類講清楚。

四種 Test Double 一張圖

flowchart TD
    Double[Test Double] --> Stub[Stub<br>給固定回應]
    Double --> Mock[Mock<br>給回應 + 驗證呼叫]
    Double --> Fake[Fake<br>簡化的真實實作]
    Double --> Spy[Spy<br>wrap 真物件 + 記錄]
    Double --> Dummy[Dummy<br>佔位、不真用]

    Stub --> St1["用：取代慢/不可控的 collaborator<br>不在乎被怎麼呼叫"]
    Mock --> Mk1["用：驗證 A 確實有呼叫 B<br>行為驗證"]
    Fake --> Fk1["用：DB → in-memory<br>邏輯類似但快"]
    Spy --> Sp1["用：保留真實行為 + 記呼叫次數"]
    Dummy --> Dm1["用：constructor 要傳但不會用到"]

    style Stub fill:#06b6d4,color:#fff
    style Mock fill:#a855f7,color:#fff
    style Fake fill:#10b981,color:#fff
    style Spy fill:#f59e0b,color:#fff

對照表

範例：登入服務測試

Stub — 給固定回應

// LoginService 依賴 UserRepository
class LoginService {
  constructor(private repo: UserRepository) {}
  async login(email: string, password: string) {
    const user = await this.repo.findByEmail(email);
    return user?.password === password;
  }
}

// Stub：給固定回應、不在乎 findByEmail 被叫幾次
const userStub: UserRepository = {
  findByEmail: async () => ({ email: '[email protected]', password: 'xxx' }),
};

const service = new LoginService(userStub);
const result = await service.login('[email protected]', 'xxx');
expect(result).toBe(true);

Mock — 驗證呼叫

const mockRepo = {
  findByEmail: jest.fn().mockResolvedValue({ email: '[email protected]', password: 'xxx' }),
};

const service = new LoginService(mockRepo);
await service.login('[email protected]', 'xxx');

// 驗證 findByEmail 真的被呼叫、用對參數
expect(mockRepo.findByEmail).toHaveBeenCalledWith('[email protected]');
expect(mockRepo.findByEmail).toHaveBeenCalledTimes(1);

Spy — 真行為 + 觀察

const realRepo = new UserRepository(realDb);
const spy = jest.spyOn(realRepo, 'findByEmail');

const service = new LoginService(realRepo);
await service.login('[email protected]', 'xxx');

// 真的去查 DB、但也記錄了呼叫
expect(spy).toHaveBeenCalledWith('[email protected]');

Fake — 簡化真實

// In-memory 取代真 DB
class FakeUserRepository implements UserRepository {
  private users = new Map<string, User>();
  async findByEmail(email: string) {
    return this.users.get(email);
  }
  async save(user: User) {
    this.users.set(user.email, user);
  }
}

const fake = new FakeUserRepository();
await fake.save({ email: '[email protected]', password: 'xxx' });

const service = new LoginService(fake);
const result = await service.login('[email protected]', 'xxx');
// 行為跟真 DB 一樣、但快且 isolated

何時用哪個

flowchart TD
    Q[要替換 collaborator?] --> Q1{要驗證<br>互動嗎?}
    Q1 -->|是| Mock[用 Mock]
    Q1 -->|否| Q2{需要真實<br>行為嗎?}
    Q2 -->|否| Stub[用 Stub]
    Q2 -->|要、但 prod 用不起| Fake[用 Fake]
    Q2 -->|要、且想加觀察| Spy[用 Spy]

    style Mock fill:#a855f7,color:#fff
    style Stub fill:#06b6d4,color:#fff
    style Fake fill:#10b981,color:#fff
    style Spy fill:#f59e0b,color:#fff

QA 在 E2E / API 測試常用

Playwright route mock (Stub)

test('handle API error', async ({ page }) => {
  await page.route('**/api/users', route => {
    route.fulfill({
      status: 500,
      body: JSON.stringify({ error: 'Server Error' }),
    });
  });
  await page.goto('/users');
  await expect(page.getByText('系統忙碌')).toBeVisible();
});

pytest + responses (Stub)

import responses

@responses.activate
def test_payment_success():
    responses.add(
        responses.POST,
        "https://api.stripe.com/v1/charges",
        json={"id": "ch_123", "status": "succeeded"},
        status=200,
    )
    result = pay(amount=100)
    assert result["status"] == "succeeded"

WireMock — 第三方 API mock server

docker run -d -p 8080:8080 wiremock/wiremock

// mappings/stripe.json
{
  "request": {
    "method": "POST",
    "url": "/v1/charges"
  },
  "response": {
    "status": 200,
    "body": "{\"id\":\"ch_123\",\"status\":\"succeeded\"}"
  }
}

MSW (Mock Service Worker) — 最現代

// src/mocks/handlers.ts
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.get('https://api.example.com/users/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Alice' });
  }),
];

MSW 強項：同一份 mock 給 Storybook / unit test / E2E 都用、超強 DX。

Mock 反模式

flowchart TD
    Anti[Mock 反模式] --> A1["Mock everything 連自己 code 都 mock"]
    Anti --> A2["驗證 implementation detail<br>(例如 someInternalFunc 被叫 3 次)"]
    Anti --> A3["Mock 跟真實 API 不同步"]
    Anti --> A4["Stub 還在用過時的 response"]
    Anti --> A5["Test 全綠但 prod 全爆"]

    style A1 fill:#ef4444,color:#fff
    style A2 fill:#ef4444,color:#fff
    style A3 fill:#ef4444,color:#fff
    style A4 fill:#ef4444,color:#fff
    style A5 fill:#ef4444,color:#fff

原則：Mock 邊界、不 Mock 自己

✓ Mock 邊界（HTTP API / DB / 第三方）
✓ Mock 不可控（時間、隨機、UUID）
✗ Mock 自己 module 的 internal function
✗ Mock 純函式

Contract Testing 補位

Mock 跟真實 API 不同步 → 用 Pact / Contract Testing 強制兩邊對齊。

工具地圖

面試常考

Q: Mock 跟 Stub 差別？

好答案（30 秒）：

Stub 給固定回應、不驗證互動 — 我設定它回什麼、test 就用。Mock 是 Stub 超集、額外驗證 collaborator 被怎麼呼叫 — 我除了設回應、還會 expect 它被呼叫過 N 次、用對參數。簡單講 Stub 是行為驗證、Mock 是互動驗證。

Q: 你會在哪些情況不用 mock？

好答案：

純函式不用、自己 module 內部的 helper 不用。Integration test 階段我會用真實 DB（in-memory Fake）。E2E 我會 mock 第三方 API（Stripe sandbox 或 stub）但保留前後端真實串接。

給 QA 的 5 句

1. 預設用 Stub、需要驗證互動才升 Mock
2. Mock 邊界、不 Mock 自己 code
3. DB / 第三方 → Fake 或 contract test
4. MSW 是 2026 後 mock 首選
5. 過度 mock 的 test 全綠但 prod 全爆

最後

Mock / Stub / Fake / Spy 是 QA 跟 dev 共通語言。用對名詞、用對位置 → 一週寫 case 順 5 倍。從每天問自己「我這真的需要 Mock 還只是 Stub？」開始、半年後你會跟 dev 對話完全不同 level。

延伸： - Test Data Management - API 測試實戰 - Microservices Contract Review