Analyzes a Python snippet and generates a pytest suite covering normal, edge and error cases, with mocks and a coverage map.
Fill in variables
The prompt below and the copied text update as you type.
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:
{{code}}你是一名资深 Python 测试工程师,精通 pytest、unittest、测试驱动开发(TDD)、模拟策略和代码覆盖率分析。
测试必须反映原始代码的预期行为,不得修改其功能。
在适当情况下使用 Python 3.10+ 的特性。
我将提供一段 Python 代码片段。请按照以下结构化流程生成一套全面的单元测试套件:
---
📋 步骤 1 — 代码分析
在编写任何测试之前,深入分析代码:
- 🎯 代码目的 :代码整体实现的功能
- ⚙️ 函数/类 :列出所有需要测试的函数和类
- 📥 输入 :所有参数、类型、有效范围及无效输入
- 📤 输出 :返回值、类型及可能的变化
- 🌿 代码分支 :识别每一个 if/else、try/except、循环路径
- 🔌 外部依赖 :需模拟的数据库调用、API 调用、文件 I/O、环境变量
- 🧨 故障点 :代码最可能出错的地方
- 🛡️ 风险区域 :误用场景、边界条件、不安全假设
在继续之前标记出任何模糊不清之处。
---
🗺️ 步骤 2 — 覆盖映射
在编写测试前,先提供完整的测试计划:
| # | 函数/类 | 测试场景 | 类别 | 优先级 |
|---|--------|----------|------|--------|
类别:
- ✅ 正常路径 — 正常预期行为
- ❌ 边界情况 — 边界值、空值、null、最大/最小值
- 💥 异常测试 — 预期错误与异常处理
- 🔁 模拟/打补丁测试 — 外部依赖隔离
- 🧪 负面输入 — 无效或恶意输入
优先级:
- 🔴 必须具备 — 核心功能、关键路径
- 🟡 应该具备 — 边界情况、错误处理
- 🔵 可有可无 — 罕见场景、信息性测试
计划测试总数:[N]
预计覆盖率:[N]%(目标为 95% 以上的行覆盖率和分支覆盖率)
| 确定性测试 | ✅ / ❌ | ... |
| 符合 PEP8 | ✅ / ❌ | ... |
| 包含文档字符串 | ✅ / ❌ | ... |
差距与建议:
- 未覆盖的任何场景及其原因
- 建议的后续步骤(集成测试、基于属性的测试、模糊测试)
- 运行测试的命令:
pytest [filename] -v --tb=short
---
这是我的 Python 代码:
{{code}}