write-tests

通过测试覆盖本地更改

用户参数

用户可以指定要重点关注的测试或模块：

$ARGUMENTS

如果未提供任何内容，则重点关注当前 Git 差异中所有尚未提交的更改。如果所有更改都已提交，则覆盖最新提交。

上下文

实现新功能或重构现有代码后，确保测试覆盖所有业务逻辑更改至关重要。此命令通过覆盖率分析和专用 Agent，协调为本地更改自动创建测试。

目标

为本地代码更改中的所有关键业务逻辑实现全面的测试覆盖。

重要约束

• 重点关注关键业务逻辑——并非每一行代码都需要 100% 覆盖
• 保留现有测试——只添加新测试，不要修改现有测试
• “分析更改的复杂度”——
  • 如果更改了 2 个或更多文件，或者一个文件包含复杂逻辑，不要自行编写测试——只能协调 Agent！
  • 如果只更改了一个文件，且更改很简单，则可以自行编写测试。

工作流步骤

准备

1. 如果有 sadd 技能，请阅读

   • 如果 sadd 技能可用，请阅读该技能，了解管理 Agent 的最佳实践

2. 了解测试基础设施

   • 阅读 @README.md 和 package.json（或同等项目配置）
   • 找出运行测试和生成覆盖率报告的命令
   • 了解项目结构和测试惯例

3. 运行所有测试

   • 执行完整测试套件，建立基线

分析

使用 haiku Agent 并行执行步骤 4–5：

4. 确认如何单独运行测试

   • 选择任意一个通过的测试文件
   • 启动 haiku Agent，让其找出单独运行此测试文件的正确命令
     • 要求其反复尝试，直到能够可靠地运行单个测试
   • Agent 完成后，如果存在特定测试文件，尝试运行该文件
   • 这样可以确保 Agent 能够单独运行测试

5. 分析本地更改

   • 运行 git status -u，找出所有更改的文件（包括未跟踪的文件）
     • 如果没有未提交的更改，则运行 git show --name-status，获取最新提交中更改的文件列表。
   • 筛除非代码文件（文档、配置等）
   • 针对每个更改的文件分别启动一个 haikue Agent，让其分析文件本身及更改的复杂度，并准备简短摘要。
   • 提取实际包含逻辑更改的文件列表

编写测试

单个简单文件流程

如果只更改了一个文件，且更改很简单，则可以自行编写测试。请遵循以下指南：

1. 阅读 TDD 技能，了解编写测试的最佳实践
2. 阅读目标文件 {FILE_PATH} 并理解其逻辑
3. 查看现有测试文件，了解其模式和风格；如果不存在，则创建测试文件。
4. 分析需要添加哪些测试用例才能覆盖这些更改。
5. 创建全面的测试，覆盖所有已确定的情况
6. 运行此前确定的测试命令。
7. 反复调整并修复问题，直到所有测试通过

确保测试满足以下要求：

• 清晰且易于维护
• 遵循项目惯例
• 测试行为，而非实现方式
• 覆盖边缘情况和错误路径

多个文件或复杂文件流程

如果有多个变更文件，或一个文件包含复杂逻辑，则需要使用专用 Agent 覆盖这些变更。遵循以下指南：

6. 并行启动 review:test-coverage-reviewer Agent（Sonnet 或 Opus 模型）

   • 每个变更文件启动一个 coverage-reviewer Agent
   • 为每个 Agent 提供：
     • 上下文：此文件中的变更（git diff）
     • 目标：要分析的具体文件
     • 资源：阅读 README 和相关文档
     • 目标：确定需要添加哪些测试套件
     • 输出：关键业务逻辑所需的测试用例列表
   • 收集所有覆盖率审查报告

7. 并行启动用于测试文件的 developer Agent（Sonnet 或 Opus 模型）

   • 为每个需要测试的变更文件启动一个 developer Agent
   • 为每个 Agent 提供：
     • 上下文：此文件的覆盖率审查报告
     • 目标：要为其创建测试的具体文件
     • 测试用例：coverage-reviewer Agent 提供的列表
     • 指南：阅读 TDD 技能（如果有），了解编写测试的最佳实践。
     • 资源：阅读 README 和测试示例
     • 命令：如何运行此文件的测试
     • 目标：为所有已识别的用例创建全面测试
     • 约束：添加新测试，不要修改现有逻辑（除非逻辑明显有问题）

8. 验证覆盖率（迭代）（Sonnet 或 Opus 模型）

   • 再次为每个文件启动 review:test-coverage-reviewer Agent
   • 提供：
     • 上下文：原始变更和新增测试
     • 目标：验证是否覆盖所有关键业务逻辑
     • 输出：确认结果或缺失覆盖项列表

9. 按需迭代

• 如果仍有文件缺少覆盖：返回第 5 步
• 仅为存在缺口的文件启动新的 developer Agent
• 提供关于仍缺少哪些内容的具体说明
• 持续迭代，直到覆盖所有关键业务逻辑

10. 最终验证

• 运行完整测试套件，确保所有测试通过
• 如果可行，生成覆盖率报告
• 验证现有测试没有发生回归

成功标准

• 变更文件中的所有关键业务逻辑都有测试覆盖 ✅
• 所有测试（新增和现有）均通过 ✅
• coverage-reviewer Agent 已验证测试质量 ✅

Agent 指令模板

覆盖率审查 Agent（初始分析）

Analyze the file {FILE_PATH} for test coverage needs.

Context: This file was modified in local changes:
{GIT_DIFF_OUTPUT}

Your task:
1. Read the changed file and understand the business logic
2. Identify all critical code paths that need testing:
   - New functions/methods added
   - Modified business logic
   - Edge cases and error handling
   - Integration points
3. Review existing tests (if any) to avoid duplication
4. Create a list of test cases needed, prioritized by importance:
   - CRITICAL: Core business logic, data mutations
   - IMPORTANT: Error handling, validations
   - NICE_TO_HAVE: Edge cases, performance

Output format:
- List of test cases with descriptions
- Priority level for each
- Suggested test file location

Developer Agent（创建测试）

Create tests for file {FILE_PATH} based on coverage analysis.

Coverage review identified these test cases:
{TEST_CASES_LIST}

Your task:
1. Read TDD skill (if available) for best practices on writing tests
2. Read @README.md for project context and testing conventions
3. Read the target file {FILE_PATH} and understand the logic
4. Review existing test files for patterns and style
5. Create comprehensive tests for all identified cases
6. Run the tests: {TEST_COMMAND}
7. Iterate until all tests pass
8. Ensure tests are:
   - Clear and maintainable
   - Follow project conventions
   - Test behavior, not implementation
   - Cover edge cases and error paths

Test command: {TEST_COMMAND}

覆盖率审查 Agent（验证）

Verify test coverage for file {FILE_PATH}.

Context: Tests were added to cover local changes in this file.

Your task:
1. Read the changed file {FILE_PATH}
2. Read the new test file(s) created
3. Verify all critical business logic is covered:
   - All new functions have tests
   - All modified logic has tests
   - Edge cases are tested
   - Error handling is tested
4. Identify any gaps in coverage
5. Confirm test quality (clear, maintainable, follows TDD principles)

Output:
- PASS: All critical business logic is covered ✅
- GAPS: List specific missing test cases that need to be added