说实话，作为开发者，我们对单元测试的心情总是很矛盾：如果不写，上线时心里发虚；如果写，又觉得枯燥乏味，浪费写业务代码的时间。
特别是面对那些复杂的业务逻辑，光是构造测试数据、Mock外部依赖、考虑边界条件，就得折腾半天。很多时候，我们喊着"TDD（测试驱动开发）"的口号，最后却变成了"HDD（侥幸驱动开发）"——赌代码不会在生产环境炸雷。
但现在，时代变了。
有了DeepSeek、通义千问这些国产大模型，写单元测试可以从"体力活"变成"指挥活"。不过，你可能也发现了一个问题：直接扔给AI一段代码，它生成的测试用例往往覆盖率低、逻辑混乱，甚至根本跑不通。
问题的关键不在于AI不够聪明，而在于你给的指令（Prompt）不够专业。
为了解决这个问题，我打磨了一套「单元测试生成专用指令」。这套指令不只是简单地让AI"写个测试"，而是把它设定为一位拥有10年经验的资深测试开发工程师，强制它按照工业级标准输出代码。
💡 为什么你需要这套指令？
普通的提问："帮我测一下这个函数。"
结果：AI给你几个简单的 assert，忽略了异常处理和边界情况。
使用本指令："执行单元测试生成任务。"
结果：AI会严格执行以下标准：
- 全维度覆盖：强制包含正常路径、边界条件（空值/极值）、异常流程。
- 结构化输出：自动生成
setUp/tearDown，测试方法命名规范（如test_功能_场景_预期）。 - 智能Mock：自动识别外部数据库或API调用，并生成标准的 Mock 代码，不用你手动去写繁琐的
patch。 - 可直接运行：连 import 语句和执行命令都给你准备好了，复制粘贴就能跑。
🛠️ 核心指令代码
请直接复制以下指令，发送给 DeepSeek、通义千问（Qwen）、Kimi 或 智谱清言（GLM）等 AI 模型：
# 角色定义
你是一位资深的测试开发工程师，拥有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. 💡 **优化建议**: 代码质量或可测试性改进建议（如有）
🚀 使用实战演示
假设你有一个Python函数，用来验证用户邮箱格式（这种正则代码最容易写错，也最需要测试）。
待测代码：
def validate_email(email):
import re
# 一个简单的正则，但可能不严谨
pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
if not email:
raise ValueError("邮箱地址不能为空")
return bool(re.match(pattern, email))
把这段代码配合上面的指令发给通义千问，你会得到一份教科书级的 pytest 测试代码：
AI会自动生成：
test_valid_email：测试标准邮箱。test_empty_email：验证是否抛出了ValueError。test_invalid_email：使用@pytest.mark.parametrize批量测试无效格式（如缺@符号、缺域名等）。- 甚至会提醒你正则可能存在的漏洞。
🎯 写在最后
工具的价值在于解放生产力。
与其花一下午时间去纠结测试用例怎么写，不如花1分钟把指令发给AI，然后用剩下的时间去优化架构、思考业务，或者干脆...准点下班。
这套指令我已经用在了很多实际项目中，无论是Java的JUnit还是前端的Jest，效果都很稳。如果你也在用国产AI辅助编程，建议把这条指令加入你的收藏夹（Prompt Library）。
动手试试吧，别让单元测试再成为你的负担。
