团队Vibe Coding开发指南 - DDAD方法论

Appearance

文档驱动的自动测试体系 ​

代码审查保证了代码的“可读性”和“可维护性”，而测试则保证了代码的“正确性”。在“团队Vibe Coding”中，我们追求的终极目标是：测试用例不应由人来编写，而应由需求文档自动生成。这确保了测试与需求之间的强一致性，彻底杜绝了“需求变了，测试没改”的经典问题。

核心理念：文档即测试 ​

这个体系的核心理念是“文档即测试”（Docs as Tests）。我们把标准化的需求文档（PRD和Task-Doc）视为一种“高级别”的测试描述语言。AI的角色则是一个“翻译官”，负责将这种高级语言“翻译”成机器可执行的具体测试代码（如Jest, Pytest, Playwright等）。

mermaid
graph TD
    A[需求文档 (PRD/Task-Doc)] --> B[AI 测试生成引擎];
    B --> C[单元测试 (Unit Tests)];
    B --> D[集成测试 (Integration Tests)];
    B --> E[端到端测试 (E2E Tests)];

    subgraph A
        A1["验收标准"]
        A2["API规范"]
        A3["用户故事"]
    end

    subgraph B
        B1["读取文档"]
        B2["分析意图"]
        B3["生成测试代码"]
    end

    C --> F[CI/CD 流水线执行]
    D --> F
    E --> F

各层级测试的自动生成 ​

1. 单元测试：从“验收标准”生成 ​

单元测试的目标是验证最小代码单元（函数、组件）的正确性。其最佳的生成来源，就是我们在Task-Doc中定义的验收标准 (Acceptance Criteria)。

工作流程：

  1. 当一个功能开发完成并提交PR时，CI流水线启动。
  2. 流水线脚本找到该功能对应的Task-Doc.md文件。
  3. 脚本将Task-Doc.md的内容，特别是“验收标准”部分，连同相关的源代码，一起提交给AI。
  4. AI根据每一条验收标准，生成一个或多个对应的单元测试用例。

Prompt示例：

你是一位资深的Jest测试工程师。

这是你要测试的React组件代码： @/features/auth/components/RegistrationForm.tsx

这是该组件的需求文档： @/docs/tasks/TASK-123-registration-form.md

请严格按照需求文档中的“验收标准”部分，为这个组件编写完整的单元测试。确保每个验收标准都至少有一个对应的test块。使用@testing-library/react进行测试。

2. 集成/API测试：从“API设计文档”生成 ​

集成测试的重点是验证不同模块或服务之间的交互是否正确。对于后端服务而言，这通常指API接口测试。其最佳生成来源是标准化的API设计文档（如OpenAPI/Swagger规范）。

工作流程：

  1. 团队在docs/api-design/目录中维护OpenAPI (v3) 格式的YAML或JSON文件。
  2. 当后端代码变更时，CI流水线读取这些API规范文件。
  3. AI或专有工具（如Postman、Schemathesis）可以解析这些规范，自动生成覆盖所有端点、参数和预期响应的API测试集合。

Prompt示例 (当没有OpenAPI规范时)：

你是一位资深的API测试专家，熟悉使用supertest和jest。

这是我们的API设计文档： @/docs/api-design/auth.md

文档中描述了 /api/v1/register 这个POST接口。请为它生成一套完整的API测试，需要覆盖以下场景：

  1. 请求成功的 happy path。
  2. 缺少必要字段（如email）的400错误。
  3. 邮箱已存在的409冲突错误。
  4. 密码格式不符合安全策略的422错误。

3. 端到端(E2E)测试：从“用户故事”生成 ​

E2E测试模拟真实用户的操作流程，验证整个系统的业务闭环。其最佳生成来源是PRD中的用户故事 (User Stories)。

工作流程：

  1. AI读取PRD中的一个核心用户故事，例如：“作为新用户，我希望能完成注册并自动登录，以便开始使用产品。”
  2. AI将这个用户故事分解为一系列具体的用户操作步骤。
  3. AI将这些步骤“翻译”成E2E测试框架（如Playwright或Cypress）的测试脚本。

Prompt示例：

你是一位Playwright自动化测试专家。

这是我们要测试的用户故事： “作为新用户，我希望能访问首页，点击‘注册’按钮，填写注册表单并提交，然后被重定向到个人仪表盘页面，并看到欢迎信息。”

请为这个用户故事生成一个完整的Playwright E2E测试脚本。请使用Page Object Model模式来组织你的代码，并为关键元素添加data-testid属性选择器。

将其融入CI/CD ​

文档驱动的测试体系的威力，在与CI/CD结合时才能完全释放。

  • PR触发：当一个PR被创建时，流水线自动为其生成单元测试和集成测试，并作为一项必须通过的检查。
  • 主干合并后触发：当代码合并到develop或main分支后，流水线触发完整的E2E测试，确保没有破坏现有的核心业务流程。

本节小结： 文档驱动的自动测试体系，是实现DevOps理念中“质量内建”和“快速反馈”的强大武器。它通过将需求文档作为生成测试的唯一来源，保证了开发与测试的绝对同步。这不仅极大地解放了人力，更重要的是，它构建了一个可靠的、自动化的质量安全网，让团队在AI的加持下，能够放心地、快速地进行迭代和交付。

下一节： 大厂经验借鉴