self-test

自测 · 检查清单

你的任务

编码完成后，按照以下清单逐项检查，确保代码质量。

测试哲学

在检查之前，先确认测试本身的质量：

好测试的特征：

• 通过公共接口验证行为，不关心内部实现
• 读起来像规格说明："用户可以带着有效购物车结算"
• 内部重构后依然通过（测试的是"做什么"，不是"怎么做"）

坏测试的特征：

• mock 内部协作者、测试私有方法
• 改了内部函数名就挂，但行为没变
• 描述的是实现细节而非用户可见行为

警告信号：如果你的测试在重构后失败，但行为没变，说明测试在测实现而非行为。

检查清单

1. 功能验证

• 每个任务的核心功能是否实现（对照计划.md 的验收标准逐条检查）
• 是否覆盖了 QA 中提到的所有场景
• 边界条件是否处理（空值、极值、异常输入）
• 错误提示是否友好（用户能看到有意义的错误信息）

2. 数据一致性

• 数据库字段是否与 Schema 描述一致
• 新增/修改/删除操作是否完整
• 数据流转是否正确（从输入到存储到展示）

3. 依赖检查

• 外部依赖（接口、表、配置）是否就绪
• 依赖的字段/列是否存在
• 同步任务/ETL 是否需要配合

4. 代码质量

• 是否有遗留的 TODO 或调试代码
• 命名是否清晰（变量、函数、文件）
• 注释是否充分（复杂逻辑处）
• 是否有重复代码可以提取

5. 兼容性

• 是否与现有功能兼容（不破坏已有逻辑）
• 接口变更是否有向后兼容处理

6. 测试质量

• 测试是否通过公共接口验证行为
• 测试是否能扛住内部重构（重命名内部函数不应让测试挂掉）
• 是否避免了横向切片（不要先批量写所有测试，再批量写所有实现）
• 测试命名是否描述了行为而非实现（"用户可以结算"而非"调用了 processOrder 函数"）

7. 视觉规格核对（对照 PRD 截图/原型）

仅当本次涉及 UI 时执行。基准是 PRD 原图，不因 计划.md 未写而跳过——上游可能漏抽截图规格。

• 字段列归属：新增字段折进已有列还是独立列，与截图一致
• 字段/筛选顺序：同一列或区域内排列顺序与截图一致
• 按钮/入口文案：与截图逐字一致，未自拟或改写
• 所在容器：按钮/筛选挂在截图指定的页签/工具栏，未擅自新建页签或区域
• 筛选项位置：与截图中现有筛选的并列关系一致
• 若实现与截图不符：修正实现，不改截图规格

反模式警示

横向切片（要避免）

❌ 错误方式：
  RED:   test1, test2, test3, test4, test5   ← 批量写测试
  GREEN: impl1, impl2, impl3, impl4, impl5   ← 批量写实现

正确方式（垂直切片）：
  test1→impl1  →  test2→impl2  →  test3→impl3  → ...

批量写的测试测的是想象中的行为，而不是实际实现的行为。每个测试应该是对前一轮实现的响应。

输出格式

## 自测结果

### ✅ 通过项
- <通过的检查项>

### ⚠️ 需注意
- <需要关注但不是阻塞的问题>

### ❌ 阻塞项
- <必须修复才能继续的问题>

注意事项

• 如果有阻塞项，回到步骤 5 修复后再继续
• 重点检查计划.md 中的验收标准是否全部满足
• 涉及 UI 时，位置/文案以 PRD 截图为准；计划.md 若与截图冲突或漏写，回原图核对并按图修正
• 测试质量检查重点看公共接口，不深入内部实现
• 自测不需要跑性能测试（除非计划.md 中明确要求）