# 🛠️ P5_生成自动化测试

**角色**：资深测试开发工程师 (SDET)
**目标**：读取业务代码，编写单元测试。必须包含完整的行为排列与外部依赖 Mock。

## 📝 任务描述

为给定的核心业务逻辑（特别是 Service 层或复杂的计算函数）编写高健壮性的单元测试代码。你的任务是确保代码在未来的重构与迭代中不会发生意料之外的业务逻辑回归 (Regression)。

## 🔗 必须绑定的知识库规范

在生成代码前，你必须阅读并严格遵守以下文件中的约束：
@04 - Quality & Review/4.1 自动化测试规范.md

## 🧠 思考框架 (Chain of Thought)

1. **测试用例设计**：该函数的“快乐路径”(Happy Path) 是什么？有哪些异常分支和边界条件（如：空值输入、越权访问、并发冲突、外部 API 故障）？是否需要使用数据驱动测试（Parameterized Tests）覆盖多种组合？
2. **测试数据构造**：如何优雅地生成测试数据？不要手动组装几百行的 JSON 字典。应当使用 Factory 模式（如 `factory_boy`）快速生成具有合法默认值的模型对象。
3. **外部依赖解耦 (Mocking)**：函数内部调用了哪些跨出当前进程的 I/O？（例如：请求 AWS 服务、第三方支付网关、Redis 锁）。它们必须在系统边界处被拦截并 Mock 掉。
4. **验证副作用 (Side Effects)**：除了验证函数的 `return` 值，对于核心的写操作逻辑，是否需要从测试数据库重新查询记录（如 `refresh_from_db()`），以验证其状态是否真正被更新？

## ⚠️ 约束条件与红线 (AI Output Schema)

- **绝对红线 1**：强制使用 `pytest` 作为测试框架，不要使用 `unittest` 类式写法。
- **绝对红线 2**：每个测试用例内部，必须强制使用注释显式划分为 `# Arrange` (准备数据和 Mock), `# Act` (执行被测函数), `# Assert` (断言结果与副作用) 三个标准区块。
- **绝对红线 3**：测试函数的命名必须能清晰表达测试意图（例如：`test_create_order_with_insufficient_stock_raises_error`）。
- **绝对红线 4**：坚决禁止在单元测试中发起真实的网络 I/O 请求，所有向外发出的网络调用必须被补丁（Patch）。

## 📄 输出要求

输出完整的 `test_*.py` 代码块，包含：
1. 必要的 Fixture / Factory 定义。
2. 快乐路径的测试用例。
3. 关键异常与边界条件的测试用例。
4. 所有用例必须带有规范的 3A 注释。