SOLO-TDD 集成

1. 概述

在 SOLO 工作模式中，测试驱动开发（TDD）是 ENGINEER 阶段的核心实践。它不是一个孤立的环节，而是与 ARCHITECT 阶段产出的 OpenAPI 规范紧密结合，构成了从设计到实现无缝衔接的关键桥梁。

通过强制 TDD，SOLO 旨在确保：

• 所有业务逻辑都有测试覆盖。
• 代码设计是可测试和模块化的。
• 实现严格遵循 API 契约。

2. TDD 在 ENGINEER 阶段的工作流

当开发者进入 ENGINEER 阶段时，他们会接收到由 ARCHITECT 定义好的 openapi.yaml 文件。基于这份契约，TDD 的工作流如下：

a. 理解 API 契约

首先，ENGINEER 需要仔细研究分配给他的 API 端点（Endpoint）的定义，包括：

• 路径 (Path) 和 HTTP 方法 (Method)。
• 请求参数 (Parameters)：路径参数、查询参数、请求头。
• 请求体 (Request Body)：结构、字段、数据类型和校验规则。
• 响应 (Responses)：不同状态码（200, 201, 400, 404 等）对应的响应体结构。

b. 编写第一个失败的测试（红灯）

基于对契约的理解，ENGINEER 开始编写测试用例。TDD 的第一步是创建一个失败的测试。

这个测试通常是一个集成测试或单元测试，它会调用尚未实现的 API 端点，并断言其行为是否符合预期。

示例 (Java/JUnit):

@Test
void whenPostValidUser_thenUserIsCreated() {
    // 准备: 构造一个有效的用户请求体
    UserRequest newUser = new UserRequest("testuser", "test@example.com");

    // 执行: 向 /users 发起 POST 请求
    ResponseEntity<UserResponse> response = restTemplate.postForEntity("/users", newUser, UserResponse.class);

    // 断言:
    // 1. 响应状态码应该是 201 Created
    assertEquals(HttpStatus.CREATED, response.getStatusCode());
    // 2. 响应体不应为空，且包含用户 ID
    assertNotNull(response.getBody());
    assertNotNull(response.getBody().getId());
    // 3. 响应体中的用户名应与请求一致
    assertEquals("testuser", response.getBody().getName());
}

在此时运行测试，它必然会失败，因为 /users 端点的 POST 逻辑还没有实现（红灯）。

c. 编写最少的代码使其通过（绿灯）

接下来，ENGINEER 的任务是编写最少的代码来让刚刚失败的测试通过。

这通常涉及：

1. 在 Controller/Router 中添加对应的处理函数。
2. 实现初步的业务逻辑，例如，将用户数据存入内存数据库或返回一个硬编码的响应。

示例 (Java/Spring Boot):

@RestController
public class UserController {

    private final Map<UUID, User> userStore = new ConcurrentHashMap<>();

    @PostMapping("/users")
    public ResponseEntity<UserResponse> createUser(@RequestBody UserRequest userRequest) {
        // 最简单的实现：创建一个用户并返回
        UUID userId = UUID.randomUUID();
        User user = new User(userId, userRequest.getName(), userRequest.getEmail());
        userStore.put(userId, user);

        UserResponse response = new UserResponse(userId, user.getName(), user.getEmail());
        return new ResponseEntity<>(response, HttpStatus.CREATED);
    }
}

再次运行测试，现在它应该会通过（绿灯）。

d. 重构（保持绿灯）

在测试通过后，ENGINEER 可以安全地对代码进行重构，以提高其质量、可读性和性能，同时要确保所有测试仍然通过。

重构可能包括：

• 将业务逻辑从 Controller 抽离到 Service 层。
• 引入数据库持久化代替内存存储。
• 优化代码结构，消除重复代码。

这个“红-绿-重构”的循环会一直持续，直到 API 端点的所有功能（包括正常流程和异常流程）都被测试覆盖和实现。

3. 契约测试的角色

除了 TDD，SOLO 还强调契约测试。在 CI/CD 流程中，自动化测试会验证 API 的实际实现是否与 openapi.yaml 契约完全一致。这确保了 TDD 过程中的任何偏离都会被及时发现，从而保障了 API-First 的核心原则。

4. 总结

SOLO-TDD 集成将 API 设计与实现紧密地联系在一起。它不仅是一种测试策略，更是一种驱动高质量代码设计与开发的方法论，是 SOLO 工作模式成功的基石。