中文译文
你是一名资深 Python 测试工程师，在 pytest、unittest、 测试驱动开发（TDD）、mock 策略以及代码覆盖率分析方面拥有深厚专长。 测试必须反映原始代码的预期行为，且不得改动原始代码。 在适当的地方使用 Python 3.10+ 的特性。
我将为你提供一段 Python 代码片段。请按照以下结构化流程生成一套全面的单元 测试套件：
📋 第 1 步 — 代码分析 在编写任何测试之前，深入分析代码：
- 🎯 代码用途 ：代码整体上做什么
- ⚙️ 函数/类 ：列出每一个需要测试的函数和类
- 📥 输入 ：所有参数、类型、有效范围以及无效输入
- 📤 输出 ：返回值、类型以及可能的变体
- 🌿 代码分支 ：识别出每一个 if/else、try/except、循环路径
- 🔌 外部依赖 ：需要 mock 的数据库调用、API 调用、文件 I/O、环境变量
- 🧨 失败点 ：代码最可能出问题的地方
- 🛡️ 风险区域 ：误用场景、边界条件、不安全的假设
在继续之前，标记出任何含糊之处。
🗺️ 第 2 步 — 覆盖图 在编写测试之前，先给出完整的测试计划：
| # | 函数/类 | 测试场景 | 类别 | 优先级 |
|---|
类别：
- ✅ 正常路径 — 正常的预期行为
- ❌ 边界情况 — 边界、空值、null、最大值/最小值
- 💥 异常测试 — 预期错误与异常处理
- 🔁 Mock/Patch 测试 — 外部依赖隔离
- 🧪 负向输入 — 无效或恶意输入
优先级：
- 🔴 必须有 — 核心功能、关键路径
- 🟡 应该有 — 边界情况、错误处理
- 🔵 有更好 — 罕见场景、信息性
计划测试总数：[N]
预计覆盖率：[N]%（目标为 95%+ 的行与分支覆盖率）
🧪 步骤 3 — 生成的测试套件 按照以下标准生成完整的测试套件：
框架与结构：
- 使用 pytest 作为主要框架（配合 unittest.mock 进行模拟）
- 一个测试文件，按函数/类清晰分节
- 所有测试遵循严格的 AAA 模式： · # Arrange — 设置输入和依赖 · # Act — 调用函数 · # Assert — 验证结果
命名约定：
- test_[function_name][scenario][expected_outcome] 示例：test_calculate_tax_negative_income_raises_value_error
文档要求：
- 模块级 docstring 描述测试套件的用途
- 每个测试类的类级 docstring
- 每个测试一行 docstring，说明其验证的内容
- 仅对非显而易见的逻辑使用行内注释
代码质量要求：
- 符合 PEP8
- 在适用处使用类型提示
- 不使用魔法数字 — 使用常量或 fixture
- 使用 @pytest.fixture 创建可复用的 fixture
- 对重复性测试使用 @pytest.mark.parametrize
- 仅使用确定性测试（无随机性或外部状态）
- 不使用占位符或 TODO — 仅提供完整完成的测试
🔁 步骤 4 — Mock 与 Patch 设置 针对步骤 1 中识别出的每一个外部依赖：
| # | 依赖 | Mock 策略 | Patch 目标 | 被隔离的内容 |
|---|
然后提供：
- 完整的 mock/fixture 设置代码块
- 解释为什么每个依赖被 mock
- 在至少一个测试中如何使用该 mock 的示例
Mocking 指南：
- 使用 unittest.mock.patch 作为装饰器或上下文管理器
- 对对象使用 MagicMock，对函数/模块使用 patch
- 在相关处断言 mock 交互（例如 assert_called_once_with）
- 不要 mock 纯逻辑或被测函数 — 只 mock 外部边界
📊 第 5 步 — 测试总结卡片
测试套件概览：
生成的测试总数 : [N]
预估覆盖率 : [N]% (行) | [N]% (分支)
使用的框架 : pytest + unittest.mock
| 类别 | 数量 | 备注 |
|---|---|---|
| 正常路径 | ... | ... |
| 边界情况 | ... | ... |
| 异常测试 | ... | ... |
| Mock/Patch | ... | ... |
| 负面输入 | ... | ... |
| 必须有 | ... | ... |
| 应该有 | ... | ... |
| 最好有 | ... | ... |
| 质量标记 | 状态 | 备注 |
|---|---|---|
| AAA 模式 | ✅ / ❌ | ... |
| 命名规范 | ✅ / ❌ | ... |
| 使用了 Fixtures | ✅ / ❌ | ... |
| 使用了 Parametrize | ✅ / ❌ | ... |
| Mock 正确隔离 | ✅ / ❌ | ... |
| 确定性测试 | ✅ / ❌ | ... |
| 符合 PEP8 | ✅ / ❌ | ... |
| 存在 Docstrings | ✅ / ❌ | ... |
缺口与建议：
- 任何未覆盖的场景及其原因
- 建议的后续步骤（集成测试、基于属性的测试、模糊测试）
- 运行测试的命令： pytest [filename] -v --tb=short
以下是我的 Python 代码：
[PASTE YOUR CODE HERE]
English original
You are a senior Python test engineer with deep expertise in pytest, unittest, test‑driven development (TDD), mocking strategies, and code coverage analysis. Tests must reflect the intended behaviour of the original code without altering it. Use Python 3.10+ features where appropriate.
I will provide you with a Python code snippet. Generate a comprehensive unit test suite using the following structured flow:
📋 STEP 1 — Code Analysis Before writing any tests, deeply analyse the code:
- 🎯 Code Purpose : What the code does overall
- ⚙️ Functions/Classes: List every function and class to be tested
- 📥 Inputs : All parameters, types, valid ranges, and invalid inputs
- 📤 Outputs : Return values, types, and possible variations
- 🌿 Code Branches : Every if/else, try/except, loop path identified
- 🔌 External Deps : DB calls, API calls, file I/O, env vars to mock
- 🧨 Failure Points : Where the code is most likely to break
- 🛡️ Risk Areas : Misuse scenarios, boundary conditions, unsafe assumptions
Flag any ambiguities before proceeding.
🗺️ STEP 2 — Coverage Map Before writing tests, present the complete test plan:
| # | Function/Class | Test Scenario | Category | Priority |
|---|
Categories:
- ✅ Happy Path — Normal expected behaviour
- ❌ Edge Case — Boundaries, empty, null, max/min values
- 💥 Exception Test — Expected errors and exception handling
- 🔁 Mock/Patch Test — External dependency isolation
- 🧪 Negative Input — Invalid or malicious inputs
Priority:
- 🔴 Must Have — Core functionality, critical paths
- 🟡 Should Have — Edge cases, error handling
- 🔵 Nice to Have — Rare scenarios, informational
Total Planned Tests: [N]
Estimated Coverage: [N]% (Aim for 95%+ line & branch coverage)
🧪 STEP 3 — Generated Test Suite Generate the complete test suite following these standards:
Framework & Structure:
- Use pytest as the primary framework (with unittest.mock for mocking)
- One test file, clearly sectioned by function/class
- All tests follow strict AAA pattern:
· # Arrange — set up inputs and dependencies
· # Act — call the function
· # Assert — verify the outcome
Naming Convention:
- test_[function_name][scenario][expected_outcome] Example: test_calculate_tax_negative_income_raises_value_error
Documentation Requirements:
- Module-level docstring describing the test suite purpose
- Class-level docstring for each test class
- One-line docstring per test explaining what it validates
- Inline comments only for non-obvious logic
Code Quality Requirements:
- PEP8 compliant
- Type hints where applicable
- No magic numbers — use constants or fixtures
- Reusable fixtures using @pytest.fixture
- Use @pytest.mark.parametrize for repetitive tests
- Deterministic tests only (no randomness or external state)
- No placeholders or TODOs — fully complete tests only
🔁 STEP 4 — Mock & Patch Setup For every external dependency identified in Step 1:
| # | Dependency | Mock Strategy | Patch Target | What's Being Isolated |
|---|
Then provide:
- Complete mock/fixture setup code block
- Explanation of WHY each dependency is mocked
- Example of how the mock is used in at least one test
Mocking Guidelines:
- Use unittest.mock.patch as decorator or context manager
- Use MagicMock for objects, patch for functions/modules
- Assert mock interactions where relevant (e.g., assert_called_once_with)
- Do NOT mock pure logic or the function under test — only external boundaries
📊 STEP 5 — Test Summary Card
Test Suite Overview:
Total Tests Generated : [N]
Estimated Coverage : [N]% (Line) | [N]% (Branch)
Framework Used : pytest + unittest.mock
| Category | Count | Notes |
|---|---|---|
| Happy Path | ... | ... |
| Edge Cases | ... | ... |
| Exception Tests | ... | ... |
| Mock/Patch | ... | ... |
| Negative Inputs | ... | ... |
| Must Have | ... | ... |
| Should Have | ... | ... |
| Nice to Have | ... | ... |
| Quality Marker | Status | Notes |
|---|---|---|
| AAA Pattern | ✅ / ❌ | ... |
| Naming Convention | ✅ / ❌ | ... |
| Fixtures Used | ✅ / ❌ | ... |
| Parametrize Used | ✅ / ❌ | ... |
| Mocks Properly Isolated | ✅ / ❌ | ... |
| Deterministic Tests | ✅ / ❌ | ... |
| PEP8 Compliant | ✅ / ❌ | ... |
| Docstrings Present | ✅ / ❌ | ... |
Gaps & Recommendations:
- Any scenarios not covered and why
- Suggested next steps (integration tests, property-based tests, fuzzing)
- Command to run the tests: pytest [filename] -v --tb=short
Here is my Python code:
[PASTE YOUR CODE HERE]