Mock vs Stub vs Fake vs Spy 完整指南 — Test Double 用對位置
Test Double 四種類型完整解釋。Mock / Stub / Fake / Spy 差別、用對位置、Playwright / pytest / Jest 實戰、第三方 API mock、WireMock / MSW / Pact 工具。
本文原刊於 qa.9niche.com,2026-08 併入 9niche.com 懶人包,內容照原文完整搬遷。
前言
「我們的 test 都用 mock」聽起來合理、實際上多數人把 Mock / Stub 混為一談、亂用一通。這篇用 Martin Fowler 的標準分類講清楚。
四種 Test Double 一張圖
對照表
| 類型 | 給回應 | 驗證呼叫 | 真實邏輯 | 何時用 |
|---|---|---|---|---|
| Dummy | ❌ | ❌ | ❌ | 不會被用、佔位 |
| Stub | ✓ 固定 | ❌ | ❌ | 取代外部、給可控資料 |
| Spy | ✓ 部分 | ✓ | ✓ | 保留行為、加觀察 |
| Mock | ✓ 可設 | ✓ 強制 | ❌ | 驗證互動 |
| Fake | ✓ 動態 | ❌ | ✓ 簡化 | 簡化的真實實作 |
範例:登入服務測試
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
何時用哪個
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 反模式
原則:Mock 邊界、不 Mock 自己
✓ Mock 邊界(HTTP API / DB / 第三方)
✓ Mock 不可控(時間、隨機、UUID)
✗ Mock 自己 module 的 internal function
✗ Mock 純函式
Contract Testing 補位
Mock 跟真實 API 不同步 → 用 Pact / Contract Testing 強制兩邊對齊。
工具地圖
| 用途 | 工具 |
|---|---|
| HTTP request mock | nock (Node) / responses (Python) |
| Service Worker | MSW |
| 完整 API mock server | WireMock / Mockoon / Beeceptor |
| Test framework 內建 | jest.mock / pytest-mock |
| Contract testing | Pact / Spring Cloud Contract |
| DB Fake | SQLite in-memory / TinyDB |
面試常考
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 句
- 預設用 Stub、需要驗證互動才升 Mock
- Mock 邊界、不 Mock 自己 code
- DB / 第三方 → Fake 或 contract test
- MSW 是 2026 後 mock 首選
- 過度 mock 的 test 全綠但 prod 全爆
最後
Mock / Stub / Fake / Spy 是 QA 跟 dev 共通語言。用對名詞、用對位置 → 一週寫 case 順 5 倍。從每天問自己「我這真的需要 Mock 還只是 Stub?」開始、半年後你會跟 dev 對話完全不同 level。
延伸:
微服務架構下 spec review 要看的東西。Consumer-Driven Contract Testing、Pact 工作流、跨服務 schema 漂移、版本兼容、事件驅動契約。
自動化測試最大坑:test data 管理。Fixture vs Factory vs Mother、Seed 策略、cleanup 模式、跨環境資料、敏感資料處理。附 pytest / Playwright 範例。
從零搭起 API 測試框架。pytest fixtures、requests session、JSON schema 驗證、auth 處理、CI 整合,附完整範例。
Performance Testing 入門 — k6 vs JMeter vs Locust 該選哪個
給 QA 看的效能測試完整入門。Load / Stress / Spike / Soak 四種類型差異、k6 實戰範例、跟 JMeter / Locust / Artillery 對比、CI 整合策略。
Playwright 定位器完全指南 — 選出打不壞的 selector
getByRole / getByLabel / getByText / getByTestId 怎麼選、CSS 與 XPath 何時用、auto-waiting 和 locator 的關係,以及 nth 與寫死 class 這類會讓測試時好時壞的反模式。
QA 必學 Python 腳本實戰指南:自動化測試、資料處理、報告生成一次搞定
QA 必學 Python 實戰指南:自動化腳本、測試資料生成、Log 分析、API 測試、報告生成、排程 6 大場景,每個都有可複製修改的程式碼範例,聚焦用 Python 解決 QA 問題。
一般聲明
本站提供之資訊僅供參考,不保證其完整性與正確性。使用者應自行判斷資訊之適用性。