name: scenario-testing description: 此技能应在编写测试、验证功能或需要确认代码正常工作时使用。触发词包括“编写测试”、“增加测试覆盖”、“验证功能”、“集成测试”、“端到端测试”、“e2e测试”、“模拟”、“单元测试”。强制要求在 .scratch/ 目录中使用真实依赖进行场景驱动测试。

AI代码生成的场景驱动测试

核心原则

铁律：“任何功能在通过真实依赖的场景测试之前，都不能被视为已验证。”

模拟（Mock）会制造虚假的信心。只有使用真实系统执行的场景才能验证代码是否正常工作。

真相层级

场景测试（真实系统，真实数据）= 真相
单元测试（隔离的）= 仅提供人类心理安慰
模拟 = 掩盖错误的谎言

正如原则所述：“使用模拟的测试并不是在测试你的系统，而是在测试你对依赖项行为的假设。”

何时使用此技能

验证新功能
在宣布工作完成之前
当想要使用模拟时
修复需要验证的bug之后
任何需要证明代码正常工作的时刻

强制性实践

1. 在 `.scratch/` 中编写场景

使用适合任务的任何语言
端到端地执行真实系统
不允许任何模拟
必须位于 .gitignore 中（永不提交）

2. 将模式提升至 `scenarios.jsonl`

将重复出现的场景提取为文档化的规范
每个场景一行JSON
包含：名称、描述、给定/当/那么、验证内容
此文件需要提交

3. 使用真实依赖

外部API必须调用实际服务（沙盒/测试模式可接受）。模拟任何依赖都会使场景无效。

4. 独立性要求

每个场景必须能够独立运行，不依赖于之前的执行。这确保了：

并行执行
防止隐藏的顺序依赖
可靠的CI/CD集成

什么使场景无效

如果场景出现以下情况，则视为无效：

包含任何形式的模拟
使用虚假数据而非真实存储
依赖于另一个场景首先运行
从未实际执行以验证其通过

需要避免的常见违规行为

拒绝以下合理化借口：

“只是个简单的单元测试……” - 单元测试不验证功能
“太简单了，不需要端到端……” - 集成问题会破坏简单功能
“为了速度，我会用模拟……” - 如果测试说谎，速度毫无意义
“我没有API凭证……” - 向你的真人伙伴索要真实的凭证

完成的定义

一个功能只有在满足以下条件时才被视为完成：

✅ .scratch/ 中的一个场景通过，且零模拟
✅ 真实依赖被调用
✅ .scratch/ 保持在 .gitignore 中
✅ 稳健的模式被提取到 scenarios.jsonl

示例工作流程

编写场景 - 创建 .scratch/test-user-registration.py
使用真实依赖 - 连接真实数据库、真实认证服务（测试模式）
运行并验证 - 执行场景，确认其通过
提取模式 - 记录到 scenarios.jsonl
保持 .scratch 被忽略 - 永不提交草稿场景

为何这很重要

单元测试 验证隔离的逻辑
集成测试 验证组件协同工作
场景测试 验证系统实际工作

只有场景测试才能证明你的功能为用户提供了价值。