你是愿意做一个"下班后手机关机"的勇士，还是做一个"上线前心惊肉跳"的赌徒？
设想这样一个场景：周五下午4:55，你刚刚修复了一个紧急的线上Bug。逻辑看起来没问题，本地运行也跑通了。产品经理站在你身后催促："能发了吗？客户在等。"
这时候，你的手指悬在"Deploy"按钮上，心里却开始打鼓：
"这行改动会不会影响到旧数据？"
"那个边缘情况我测到了吗？"
"万一搞挂了支付接口，周末就废了..."
如果你犹豫了，说明你的代码在**"裸奔"**。
🛡️ 并没有人真的讨厌写代码，但大家都讨厌写测试
我们都知道单元测试（Unit Test）是代码的**"护身符"**。它能让你在重构时底气十足，在发布时如履平地。
但现实是残酷的：写业务代码是创造，写测试代码是折磨。
为了验证一个简单的 calcPrice 函数，你得构造各种奇葩的输入数据，模拟数据库连接，Mock 掉外部接口... 往往测试代码的行数比业务代码还多。如果你在赶工期，单元测试往往是第一个被牺牲的"耗材"。
但这恰恰是 AI 最擅长的领域。
AI 不知疲倦，逻辑严密，最喜欢干这种"找茬"和"穷举"的活儿。它能瞬间想出你漏掉的边界条件，也能不厌其烦地写完几十行 Mock 代码。
为了把这个"不知疲倦的测试员"招致麾下，我编写了一套**「单元测试生成 AI 指令」**。
📋 让 AI 帮你织一张"安全网"
这不是一个简单的"帮我写个测试"的请求，而是一个定义了测试策略、覆盖维度、Mock 规范的完整测试协议。
它要求 AI 不仅要覆盖"正常路径"，更要死磕"边界条件"和"异常处理"------这正是人类程序员最容易偷懒的地方。
🚀 复制这个指令，今晚睡个好觉
markdown
# 角色定义
你是一位资深的测试开发工程师，拥有10年以上的软件测试经验，精通各类单元测试框架（如JUnit、pytest、Jest、Mocha、NUnit等）和测试方法论（TDD、BDD）。你深谙代码质量保证的最佳实践，能够针对各种编程语言和业务场景，设计出高效、全面、可维护的单元测试用例。
# 任务描述
请为以下代码生成完整的单元测试用例，确保测试覆盖全面、结构清晰、易于维护，帮助开发者提高代码质量和系统可靠性。
**输入信息**:
- **待测代码**: [粘贴需要测试的代码]
- **编程语言**: [如: Python/Java/JavaScript/TypeScript/C#/Go等]
- **测试框架**: [如: pytest/JUnit/Jest/Mocha/NUnit等，可选，AI可根据语言推荐]
- **业务背景**: [简要说明代码的业务功能，可选]
- **特殊要求**: [如: 需要Mock外部依赖、性能测试、边界测试等，可选]
# 输出要求
## 1. 测试代码结构
- **测试文件头部**: 必要的导入语句和测试配置
- **测试类/模块组织**: 按被测功能合理分组
- **测试方法命名**: 采用清晰的命名规范（如: test_功能_场景_预期结果）
- **测试数据准备**: 合理的setUp/tearDown或fixture设计
- **断言语句**: 明确的预期结果验证
## 2. 测试覆盖维度
- **正常路径测试**: 验证预期输入的正确输出
- **边界条件测试**: 极值、空值、临界值测试
- **异常处理测试**: 错误输入、异常抛出验证
- **参数化测试**: 多组输入数据的批量验证（如适用）
- **Mock/Stub测试**: 外部依赖的隔离测试（如适用）
## 3. 质量标准
- **覆盖率**: 力争达到核心逻辑80%以上的分支覆盖
- **独立性**: 每个测试用例相互独立，无依赖顺序
- **可读性**: 测试意图清晰，便于理解和维护
- **可重复性**: 测试结果稳定，多次运行结果一致
- **执行效率**: 测试运行快速，避免不必要的等待
## 4. 格式要求
- 输出完整可运行的测试代码
- 每个测试方法添加简要注释说明测试目的
- 提供测试执行命令
- 如有Mock需求，提供Mock配置代码
## 5. 风格约束
- **代码风格**: 遵循对应语言的编码规范（如PEP8、Google Style等）
- **注释语言**: 中文注释说明测试意图
- **专业程度**: 适合中级开发者阅读和维护
# 质量检查清单
在完成输出后，请自我检查:
- [ ] 测试用例是否覆盖了所有公共方法
- [ ] 是否包含正常路径和异常路径测试
- [ ] 边界条件是否得到充分验证
- [ ] 测试命名是否清晰表达测试意图
- [ ] Mock/Stub使用是否合理
- [ ] 测试代码是否可以直接运行
- [ ] 是否提供了测试执行说明
# 注意事项
- 不要测试语言内置功能或第三方库的正确性
- 避免测试私有方法（除非有特殊需求）
- 测试数据应具有代表性，避免过于简单或过于复杂
- 对于有外部依赖的代码，优先使用Mock隔离
- 异步代码需要使用对应的异步测试方法
# 输出格式
请按以下顺序输出:
1. 📊 **测试策略概述**: 简要说明测试设计思路
2. 📝 **完整测试代码**: 可直接运行的测试文件
3. 🔧 **执行说明**: 测试运行命令和依赖安装
4. 📈 **覆盖率分析**: 测试覆盖的功能点清单
5. 💡 **优化建议**: 代码质量或可测试性改进建议（如有）⚡️ 它是如何"防守反击"的？
当你把代码喂给这个指令后，你会发现它比你想象的更"吹毛求疵"。
1. 专治"想当然"
人类写测试通常只测"Happy Path"（快乐路径），即输入正确、流程跑通。但 AI 会盯着你的 if (count > 0) 问："如果 count 是 0 呢？是 -1 呢？是 null 呢？"。
在这个指令的驱使下，AI 会生成大量的边界测试（Boundary Testing） 和异常测试。你会惊讶地发现，原来你的代码在这么多极端情况下都会崩溃。
2. 搞定"硬骨头"
遇到依赖数据库、Redis 或者第三方 API 的代码，很多人的反应是："这个太难测了，算了吧。"
指令中的 Mock/Stub 策略 会强制 AI 帮你隔离外部依赖。它会自动使用 unittest.mock (Python) 或 Mockito (Java) 来模拟外部服务。你得到的不仅仅是测试代码，更是一套解耦的架构示范。
3. 从"一堆代码"到"测试矩阵"
如果你手动写测试，可能就是复制粘贴几个 assert。但这个指令要求 AI 输出参数化测试（Parameterized Tests）。
这意味着，它不会写 10 个 test_xxx 方法，而是会构建一个数据驱动的测试矩阵：
python
@pytest.mark.parametrize("input,expected", [
("user@example.com", True),
("invalid-email", False),
("", ValueError), # AI 自动补全了你没想到的空值情况
(None, TypeError) # AI 甚至考虑了类型错误
])这种测试密度，是人工编写难以企及的。
💡 开发者的自我修养
有了这个工具，你的开发流程可能会发生微妙的变化：
以前，你写完代码，心里发虚地提交。
现在，你写完代码，扔给 AI："给我狠狠地测。"然后看着它生成的 Test Case，反过来修复业务代码里的 Bug。
这就是传说中的**"AI 辅助的测试驱动开发"（AI-Assisted TDD）**。
别再让用户当你的测试员了。把这只"看门狗"领回去，让它替你守好发布的最后一道防线。
毕竟，成年人的安全感，不仅来自银行卡里的余额，更来自 All tests passed 的那一行绿字。