单元测试实战：编写可维护的测试代码

测试金字塔

        /\
       /  \
      / E2E \     少量
     /------\
    /        \
   /  集成测试  \   适量
  /------------\
 /              \
/   单元测试      \  大量
------------------

AAA 模式

test("用户登录成功返回 token", () => {
  // Arrange - 准备数据
  const user = { email: "test@test.com", password: "123456" };
  
  // Act - 执行操作
  const result = await login(user);
  
  // Assert - 断言结果
  expect(result.token).toBeDefined();
  expect(result.user.email).toBe(user.email);
});

测试命名规范

// 清晰描述测试场景
test("should_return_401_when_token_invalid");
test("should_create_user_when_data_valid");

Mock 和 Stub

// Mock 外部依赖
jest.mock("./database");
db.query.mockResolvedValue([{ id: 1 }]);

// 验证调用
test("调用数据库查询", () => {
  getUser(1);
  expect(db.query).toHaveBeenCalledWith("SELECT * FROM users WHERE id = ?", [1]);
});

测试覆盖率

# 运行测试并生成覆盖率报告
npm test -- --coverage

目标：核心业务逻辑 80%+ 覆盖率。

常见陷阱

• ❌ 测试过于复杂难以维护
• ❌ 测试之间相互依赖
• ❌ 只测试 happy path
• ❌ 断言不够精确

最佳实践

• 测试要快、独立、可重复
• 测试代码也要重构
• 先写测试再写实现（TDD）
• 测试是文档，要易读

好的测试是代码的安全网。