Back to Details

test-antipatterns

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Testing Anti-Patterns

测试反模式

Overview

概述

Tests must verify real behavior, not mock behavior. Mocks are a means to isolate, not the thing being tested.
Core principle: Test what the code does, not what the mocks do.
These principles prevent these anti-patterns when applied consistently.
测试必须验证真实行为，而非mock行为。Mock是实现隔离的手段，而非测试对象。
核心原则： 测试代码的实际功能，而非mock的功能。
始终如一地践行这些原则可以避免以下反模式。

The Iron Laws

铁律

1. NEVER test mock behavior
2. NEVER add test-only methods to production classes
3. NEVER mock without understanding dependencies
1. NEVER test mock behavior
2. NEVER add test-only methods to production classes
3. NEVER mock without understanding dependencies

Anti-Pattern 1: Testing Mock Behavior

反模式1：测试mock行为

The violation:
typescript
// ❌ BAD: Testing that the mock exists
test('renders sidebar', () => {
  render(<Page />);
  expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
});
Why this is wrong:
  • You're verifying the mock works, not that the component works
  • Test passes when mock is present, fails when it's not
  • Tells you nothing about real behavior
your human partner's correction: "Are we testing the behavior of a mock?"
The fix:
typescript
// ✅ GOOD: Test real component or don't mock it
test('renders sidebar', () => {
  render(<Page />);  // Don't mock sidebar
  expect(screen.getByRole('navigation')).toBeInTheDocument();
});

// OR if sidebar must be mocked for isolation:
// Don't assert on the mock - test Page's behavior with sidebar present
违规案例：
typescript
// ❌ 错误示例：测试mock是否存在
test('renders sidebar', () => {
  render(<Page />);
  expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
});
错误原因：
  • 你在验证mock是否有效，而非组件是否正常工作
  • 只要mock存在测试就会通过，mock不存在就会失败
  • 完全无法体现真实的功能表现
你的协作伙伴纠错提示： "我们是在测试mock的行为吗？"
修复方案：
typescript
// ✅ 正确示例：测试真实组件，或是不mock该组件
test('renders sidebar', () => {
  render(<Page />);  // 不要mock侧边栏
  expect(screen.getByRole('navigation')).toBeInTheDocument();
});

// 或者如果出于隔离需要必须mock侧边栏：
// 不要对mock做断言 —— 测试侧边栏存在时Page的行为即可

Gate Function

校验逻辑

BEFORE asserting on any mock element:
  Ask: "Am I testing real component behavior or just mock existence?"

  IF testing mock existence:
    STOP - Delete the assertion or unmock the component

  Test real behavior instead
对任意mock元素做断言之前：
  问自己："我是在测试真实组件的行为，还是仅仅在测试mock是否存在？"

  如果是在测试mock是否存在：
    停下来 —— 删除这个断言，或是取消对组件的mock

  转而测试真实的功能表现

Anti-Pattern 2: Test-Only Methods in Production

反模式2：生产代码中存在仅测试用途的方法

The violation:
typescript
// ❌ BAD: destroy() only used in tests
class Session {
  async destroy() {
    // Looks like production API!
    await this._workspaceManager?.destroyWorkspace(this.id);
    // ... cleanup
  }
}

// In tests
afterEach(() => session.destroy());
Why this is wrong:
  • Production class polluted with test-only code
  • Dangerous if accidentally called in production
  • Violates YAGNI and separation of concerns
  • Confuses object lifecycle with entity lifecycle
The fix:
typescript
// ✅ GOOD: Test utilities handle test cleanup
// Session has no destroy() - it's stateless in production

// In test-utils/
export async function cleanupSession(session: Session) {
  const workspace = session.getWorkspaceInfo();
  if (workspace) {
    await workspaceManager.destroyWorkspace(workspace.id);
  }
}

// In tests
afterEach(() => cleanupSession(session));
违规案例：
typescript
// ❌ 错误示例：destroy() 仅在测试中被使用
class Session {
  async destroy() {
    // 看起来就像是生产环境的API!
    await this._workspaceManager?.destroyWorkspace(this.id);
    // ... 其他清理逻辑
  }
}

// 测试代码中
afterEach(() => session.destroy());
错误原因：
  • 生产类被仅测试用途的代码污染
  • 如果在生产环境被意外调用会非常危险
  • 违反YAGNI原则和关注点分离原则
  • 混淆了对象生命周期和实体生命周期
修复方案：
typescript
// ✅ 正确示例：用测试工具函数处理测试清理逻辑
// Session类中没有destroy()方法 —— 生产环境中它是无状态的

// 在 test-utils/ 目录下
export async function cleanupSession(session: Session) {
  const workspace = session.getWorkspaceInfo();
  if (workspace) {
    await workspaceManager.destroyWorkspace(workspace.id);
  }
}

// 测试代码中
afterEach(() => cleanupSession(session));

Gate Function

校验逻辑

BEFORE adding any method to production class:
  Ask: "Is this only used by tests?"

  IF yes:
    STOP - Don't add it
    Put it in test utilities instead

  Ask: "Does this class own this resource's lifecycle?"

  IF no:
    STOP - Wrong class for this method
向生产类添加任意方法之前：
  问自己："这个方法是不是仅会被测试使用？"

  如果是：
    停下来 —— 不要添加这个方法
    把它放到测试工具函数中

  问自己："这个类是否拥有该资源的生命周期管理权？"

  如果不是：
    停下来 —— 这个方法不属于这个类

Anti-Pattern 3: Mocking Without Understanding

反模式3：未理解依赖就进行mock

The violation:
typescript
// ❌ BAD: Mock breaks test logic
test("detects duplicate server", () => {
  // Mock prevents config write that test depends on!
  vi.mock("ToolCatalog", () => ({
    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined),
  }));

  await addServer(config);
  await addServer(config); // Should throw - but won't!
});
Why this is wrong:
  • Mocked method had side effect test depended on (writing config)
  • Over-mocking to "be safe" breaks actual behavior
  • Test passes for wrong reason or fails mysteriously
The fix:
typescript
// ✅ GOOD: Mock at correct level
test("detects duplicate server", () => {
  // Mock the slow part, preserve behavior test needs
  vi.mock("MCPServerManager"); // Just mock slow server startup

  await addServer(config); // Config written
  await addServer(config); // Duplicate detected ✓
});
违规案例：
typescript
// ❌ 错误示例：mock破坏了测试依赖的逻辑
test("detects duplicate server", () => {
  // mock屏蔽了测试依赖的配置写入操作!
  vi.mock("ToolCatalog", () => ({
    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined),
  }));

  await addServer(config);
  await addServer(config); // 本应该抛出错误，但不会触发!
});
错误原因：
  • 被mock的方法存在测试依赖的副作用（写入配置）
  • 为了"安全"过度mock反而破坏了实际的行为逻辑
  • 测试会因为错误的原因通过，或是出现莫名其妙的失败
修复方案：
typescript
// ✅ 正确示例：在正确的层级做mock
test("detects duplicate server", () => {
  // 只mock慢的部分，保留测试需要的行为
  vi.mock("MCPServerManager"); // 仅mock慢的服务启动逻辑

  await addServer(config); // 配置正常写入
  await addServer(config); // 正常检测到重复 ✓
});

Gate Function

校验逻辑

BEFORE mocking any method:
  STOP - Don't mock yet

  1. Ask: "What side effects does the real method have?"
  2. Ask: "Does this test depend on any of those side effects?"
  3. Ask: "Do I fully understand what this test needs?"

  IF depends on side effects:
    Mock at lower level (the actual slow/external operation)
    OR use test doubles that preserve necessary behavior
    NOT the high-level method the test depends on

  IF unsure what test depends on:
    Run test with real implementation FIRST
    Observe what actually needs to happen
    THEN add minimal mocking at the right level

  Red flags:
    - "I'll mock this to be safe"
    - "This might be slow, better mock it"
    - Mocking without understanding the dependency chain
mock任意方法之前：
  先停下来 —— 别急着mock

  1. 问自己："真实方法有哪些副作用？"
  2. 问自己："当前测试是否依赖这些副作用中的任何一个？"
  3. 问自己："我是否完全清楚这个测试需要什么？"

  如果依赖相关副作用：
    在更低的层级做mock（实际的慢/外部操作）
    或是使用保留了必要行为的测试替身
    不要mock测试依赖的高层级方法

  如果不确定测试依赖什么：
    先用真实实现运行测试
    观察实际需要运行的逻辑
    再在正确的层级添加最少的mock

  危险信号：
    - "我先mock一下这个更安全"
    - "这个可能很慢，最好mock掉"
    - 不理解依赖链就进行mock

Anti-Pattern 4: Incomplete Mocks

反模式4：不完整的mock

The violation:
typescript
// ❌ BAD: Partial mock - only fields you think you need
const mockResponse = {
  status: "success",
  data: { userId: "123", name: "Alice" },
  // Missing: metadata that downstream code uses
};

// Later: breaks when code accesses response.metadata.requestId
Why this is wrong:
  • Partial mocks hide structural assumptions - You only mocked fields you know about
  • Downstream code may depend on fields you didn't include - Silent failures
  • Tests pass but integration fails - Mock incomplete, real API complete
  • False confidence - Test proves nothing about real behavior
The Iron Rule: Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses.
The fix:
typescript
// ✅ GOOD: Mirror real API completeness
const mockResponse = {
  status: "success",
  data: { userId: "123", name: "Alice" },
  metadata: { requestId: "req-789", timestamp: 1234567890 },
  // All fields real API returns
};
违规案例：
typescript
// ❌ 错误示例：部分mock —— 只 mock 了你认为需要的字段
const mockResponse = {
  status: "success",
  data: { userId: "123", name: "Alice" },
  // 缺失了下游代码要用到的metadata字段
};

// 后续：当代码访问 response.metadata.requestId 时就会报错
错误原因：
  • 部分mock隐藏了结构假设 —— 你只mock了你知道的字段
  • 下游代码可能依赖你没有包含的字段 —— 会出现静默失败
  • 测试通过但集成失败 —— mock不完整，但真实API是完整的
  • 错误的信心 —— 测试完全无法验证真实行为
铁则： 要mock完整的真实数据结构，而不是仅mock当前测试用到的字段。
修复方案：
typescript
// ✅ 正确示例：完整复刻真实API的返回结构
const mockResponse = {
  status: "success",
  data: { userId: "123", name: "Alice" },
  metadata: { requestId: "req-789", timestamp: 1234567890 },
  // 包含真实API返回的所有字段
};

Gate Function

校验逻辑

BEFORE creating mock responses:
  Check: "What fields does the real API response contain?"

  Actions:
    1. Examine actual API response from docs/examples
    2. Include ALL fields system might consume downstream
    3. Verify mock matches real response schema completely

  Critical:
    If you're creating a mock, you must understand the ENTIRE structure
    Partial mocks fail silently when code depends on omitted fields

  If uncertain: Include all documented fields
创建mock响应之前：
  检查："真实API响应包含哪些字段？"

  操作：
    1. 查看文档/示例中的真实API响应
    2. 包含系统下游可能用到的所有字段
    3. 验证mock完全匹配真实响应的结构

  关键点：
    如果你要创建mock，就必须理解完整的结构
    当代码依赖被省略的字段时，部分mock会出现静默失败

  如果不确定：包含所有文档中注明的字段

Anti-Pattern 5: Integration Tests as Afterthought

反模式5：集成测试事后补

The violation:
✅ Implementation complete
❌ No tests written
"Ready for testing"
Why this is wrong:
  • Testing is part of implementation, not optional follow-up
  • Can't claim complete without tests
  • Tests written alongside implementation catch issues early
The fix:
Tests are part of implementation:
1. Write tests alongside implementation
2. Verify behavior works correctly
3. Refactor as needed
4. THEN claim complete
违规案例：
✅ 功能开发完成
❌ 没写任何测试
"可以提测了"
错误原因：
  • 测试是开发的一部分，不是可选的后续环节
  • 没有测试就不能宣称功能开发完成
  • 开发过程中同步写测试可以更早发现问题
修复方案：
测试是开发的一部分：
1. 开发功能的同时编写测试
2. 验证功能表现正常
3. 按需进行重构
4. 之后再宣称开发完成

When Mocks Become Too Complex

Mock过于复杂的情况

Warning signs:
  • Mock setup longer than test logic
  • Mocking everything to make test pass
  • Mocks missing methods real components have
  • Test breaks when mock changes
your human partner's question: "Do we need to be using a mock here?"
Consider: Integration tests with real components often simpler than complex mocks
警告信号：
  • mock的配置代码比测试逻辑还长
  • 为了让测试通过mock了所有内容
  • mock缺少真实组件拥有的方法
  • mock改动时测试就会失败
你的协作伙伴提示问题： "我们这里真的需要用mock吗？"
建议： 使用真实组件做集成测试往往比复杂的mock更简单

Quick Reference

快速参考

Anti-PatternFix
Assert on mock elementsTest real component or unmock it
Test-only methods in productionMove to test utilities
Mock without understandingUnderstand dependencies first, mock minimally
Incomplete mocksMirror real API completely
Tests as afterthoughtTests are part of implementation
Over-complex mocksConsider integration tests
反模式修复方案
对mock元素做断言测试真实组件或是取消mock
生产代码中存在仅测试方法移动到测试工具函数中
未理解依赖就mock先理解依赖，做最小化mock
不完整的mock完整复刻真实API的结构
测试事后补测试是开发流程的一部分
过度复杂的mock考虑使用集成测试

Red Flags

危险信号

  • Assertion checks for 
    *-mock
    test IDs
  • Methods only called in test files
  • Mock setup is >50% of test
  • Test fails when you remove mock
  • Can't explain why mock is needed
  • Mocking "just to be safe"
  • 断言检查
    *-mock
    格式的测试ID
  • 方法仅在测试文件中被调用
  • mock配置占测试代码的50%以上
  • 移除mock后测试就会失败
  • 无法解释为什么需要mock
  • "只是为了安全"而做mock

The Bottom Line

总结

Mocks are tools to isolate, not things to test.
If you're testing mock behavior, you've gone wrong.
Fix: Test real behavior or question why you're mocking at all.
Mock是用于实现隔离的工具，而非测试对象。
如果你在测试mock的行为，那你的方向就错了。
修复方案：测试真实行为，或是反思你为什么要使用mock。