📚 课程目录第4章测试驱动开发(TDD)入门

4. 测试驱动开发(TDD)入门：红-绿-重构循环、单元测试与集成测试的区别、TDD在接口开发中的实践

4.1 什么是测试驱动开发？

测试驱动开发（Test-Driven Development，TDD）是一种先写测试、后写实现代码的开发方法论。其核心思想是通过测试来驱动代码的设计与演进，而非在代码完成后补写测试。TDD 遵循一个严格的“红-绿-重构”循环，确保每一行生产代码都有对应的测试用例覆盖。

  核心理念： 测试不是验证手段，而是设计工具。TDD 迫使开发者在编写代码前先思考接口契约、边界条件和预期行为。

4.2 红-绿-重构循环详解

TDD 的每一次迭代都包含三个明确阶段，形成一个闭环：

红（Red）： 编写一个失败的测试用例。此时尚未编写实现代码，测试预期会失败（IDE 或测试框架显示红色）。
绿（Green）： 编写刚好足够的实现代码，使测试通过（显示绿色）。不追求完美，只求通过当前测试。
重构（Refactor）： 在测试保护下，对代码进行优化——消除重复、提升可读性、改进设计，同时确保测试依然通过。

实践要点： 在“绿”阶段，允许写“脏代码”，只要测试通过即可。重构阶段才是打磨代码的时机。切忌在“绿”阶段过度设计。

4.3 单元测试与集成测试的区别

在 TDD 实践中，正确区分单元测试和集成测试至关重要。两者在测试范围、依赖管理和执行速度上存在显著差异：

维度	单元测试	集成测试
测试范围	单个函数、方法或类	多个模块、组件或系统间的交互
外部依赖	使用 Mock / Stub 隔离	使用真实或嵌入式依赖（数据库、消息队列等）
执行速度	毫秒级，可频繁运行	秒级到分钟级，运行频率较低
失败定位	精准定位到具体代码行	定位到交互链路，需进一步排查
测试数量	占总量 70% 以上（测试金字塔底层）	占总量 20% 左右（测试金字塔中层）
TDD 适用性	非常适合，驱动细粒度设计	部分适用，通常先写单元测试再补集成测试

常见误区： 将集成测试当作单元测试来写（依赖未隔离），或将单元测试写成集成测试（依赖真实数据库）。TDD 的“红-绿”循环主要针对单元测试，集成测试更适合在功能稳定后补充。

4.4 TDD 在接口开发中的实践

将 TDD 应用于后端接口开发，通常遵循以下步骤：

定义接口契约： 确定 HTTP 方法、路径、请求参数、响应格式和状态码。
编写单元测试（红）： 针对 Service 层或 Handler 层的核心逻辑编写测试，使用 Mock 隔离数据库和外部服务。
实现最小代码（绿）： 编写刚好满足测试的代码，不引入额外逻辑。
重构代码： 优化实现，提取公共逻辑，确保测试依然通过。
补充集成测试： 使用 Testcontainers 或嵌入式数据库验证真实链路。

以下是一个使用 Go 语言对用户注册接口进行 TDD 的示例：

// 1. 红阶段：编写失败测试
func TestRegisterUser_Success(t *testing.T) {
    mockRepo := new(MockUserRepository)
    mockRepo.On("FindByEmail", "test@example.com").Return(nil, nil)
    mockRepo.On("Create", mock.AnythingOfType("*User")).Return(nil)

    svc := NewUserService(mockRepo)
    req := &RegisterRequest{Email: "test@example.com", Password: "Pass123!"}
    resp, err := svc.Register(context.Background(), req)

    assert.NoError(t, err)
    assert.Equal(t, http.StatusCreated, resp.StatusCode)
    mockRepo.AssertExpectations(t)
}

// 2. 绿阶段：编写最小实现
func (s *UserService) Register(ctx context.Context, req *RegisterRequest) (*RegisterResponse, error) {
    existing, _ := s.repo.FindByEmail(req.Email)
    if existing != nil {
        return nil, ErrEmailAlreadyExists
    }
    user := &User{Email: req.Email, Password: hashPassword(req.Password)}
    if err := s.repo.Create(user); err != nil {
        return nil, err
    }
    return &RegisterResponse{StatusCode: http.StatusCreated, UserID: user.ID}, nil
}

// 3. 重构阶段：提取密码哈希、参数校验等公共逻辑
func (s *UserService) Register(ctx context.Context, req *RegisterRequest) (*RegisterResponse, error) {
    if err := req.Validate(); err != nil {
        return nil, err
    }
    existing, _ := s.repo.FindByEmail(req.Email)
    if existing != nil {
        return nil, ErrEmailAlreadyExists
    }
    user := &User{Email: req.Email, Password: s.hasher.Hash(req.Password)}
    if err := s.repo.Create(user); err != nil {
        return nil, err
    }
    return &RegisterResponse{StatusCode: http.StatusCreated, UserID: user.ID}, nil
}

4.5 TDD 在接口开发中的收益与挑战

维度	收益	挑战
代码质量	接口契约清晰，边界覆盖完整，回归风险低	初期编写测试耗时，对开发者习惯要求高
设计演进	强制解耦，依赖注入自然形成	对 Mock 框架的熟练度要求高，过度 Mock 可能掩盖问题
团队协作	测试即文档，新成员可快速理解接口行为	测试维护成本随接口变更而增加
压测前置	单元测试通过后，可快速构建压测脚本验证性能基线	压测场景需独立设计，与 TDD 测试关注点不同

压测场景建议： 在 TDD 的“重构”阶段完成后，立即将单元测试中的核心逻辑提取为压测场景的校验点。例如，将 RegisterUser_Success 中的响应断言直接复用到压测脚本的响应校验函数中，确保压测流量不仅跑通，而且结果正确。

4.6 小结

TDD 的“红-绿-重构”循环为后端接口开发提供了一种严谨、可重复的质量保障机制。单元测试驱动细粒度设计，集成测试验证真实链路，两者互补构成测试金字塔的坚实底座。在接口开发中实践 TDD，不仅能提前暴露设计缺陷，还能为后续的压测场景提供可靠的校验基线，是后端性能工程的重要前置环节。