返回提示词库Back to prompts
语言当前显示中英对照
开发编程coding
Python Unit Test Generator — Comprehensive, Coverage Mapped & Production Ready
来自 prompts.chat 开放提示词库的公开模板，适合代码、调试和开发工作。正文保留原文，方便直接复制使用。
An open prompt template from prompts.chat for coding, debugging, and development. The original wording is preserved for direct copying.
ChatGPTClaudeGeminiCodex
0 次复制copies·小黑丸整理Curated by XHW
提示词正文Prompt text
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]
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]
使用场景Best used for
适合代码、调试和开发工作，使用前请替换其中的角色、主题和具体约束。
Useful for coding, debugging, and development. Replace the role, topic, and constraints before using it.
使用提醒Usage note
这条内容来自 prompts.chat 公开提示词库；说明为中英对照，正文保留来源原文。使用前请检查并按自己的工作场景改写。
Sourced from the prompts.chat public library. Descriptions are bilingual; the prompt preserves the original text. Review and adapt it to your work before use.