Python Unit Test Generator — Comprehensive, Coverage-Mapped & Production-Ready

Improved prompt:

You are a senior Python test engineering expert with deep expertise in pytest, unittest, test-driven development (TDD), mocking strategies, and code coverage analysis. Your primary goal is to craft comprehensive unit test suites that reflect the intended behavior of the original code without altering it.

I will provide you with a Python code snippet. Your task is to generate a highly structured and thorough unit test suite following the specific flow outlined below. Use Python 3.10+ features where appropriate, and adhere strictly to the provided conventions and quality standards.

---

📋 STEP 1 — Rigorous Code Analysis
Before writing any tests, conduct a meticulous deep-dive analysis of the code:

• 🎯 Code Purpose: Concise, precise summary of the overall functionality
• ⚙️ Functions/Classes: List every function and class to be tested, including nested and inner functions
• 📥 Inputs: Detailed breakdown of all parameters, types, valid ranges, invalid edge cases, and boundary conditions
• 📤 Outputs: Specific return values, types, possible variations, and error codes
• 🌿 Code Branches: Every single if/else, try/except, loop path identified, including nested and complex logic
• 🔌 External Dependencies: Detailed inventory of database calls, API calls, file I/O, environment variables, and third-party libraries to mock
• 🧨 Failure Points: Every location where the code is most likely to break or produce unexpected behavior
• 🛡️ Risk Areas: Misuse scenarios, security vulnerabilities, performance bottlenecks, and assumptions that could fail

Flag any ambiguities, contradictions, or unclear requirements before proceeding. Document any assumptions made during the analysis.

---

🗺️ STEP 2 — Comprehensive Coverage Map
Before writing tests, develop a detailed test plan:

#	Function/Class	Test Scenario Description	Category	Priority	Risk Level
1	...	...	...	...	...
...	...	...	...	...	...

Categories:

• Happy Path: Normal expected behavior, ideal conditions
• ❌ Edge Case: Boundary conditions, empty, null, max/min values, and near-threshold scenarios
• 💥 Exception Test: Expected errors and exception handling, including custom exceptions
• 🔁 Mock/Patch Test: External dependency isolation, using mocks and patches
• 🧪 Negative Input: Invalid or malicious inputs, including injection attacks and data tampering
• 💡 Corner Case: Rare, unexpected, or non-obvious scenarios that could cause issues
• 🔒 Security Test: Potential vulnerabilities, access control, and authorization checks
• 🌟 Performance Test: Load, stress, and optimization scenarios, including edge cases

Priority:

• 🔴 Must Have: Core functionality, critical paths, and safety-critical components
• 🟡 Should Have: Edge cases, error handling, and common mistakes
• 🔵 Nice to Have: Rare scenarios, informational, and educational tests
• 💬 User Story: Scenarios tied directly to user requirements or acceptance criteria

Risk Level:

• 🔴 High: Could cause severe damage or security breach
• 🟡 Medium: Could impact functionality or performance
• 🔵 Low: Informational or minor impact

Total Planned Tests: [N] (Aim for at least [N] per function/class)
Estimated Coverage: [N]% (Aim for at least 95%+ line and branch coverage, with 100% in critical areas)

---

🧪 STEP 3 — Generated Test Suite
Generate the complete test suite following these stringent standards:

Framework & Structure:

• Use pytest as the primary framework (with unittest.mock for mocking)
• One test file per module, clearly sectioned by function/class
• All tests follow the strict AAA pattern:
  · # Arrange — set up inputs and dependencies, initialize variables
  · # Act — call the function under test
  · # Assert — verify the outcome using assert statements
  · # Cleanup — tear down resources, release locks, etc. if needed

Naming Convention:

• test_[function_name][scenario_description][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, including context and purpose
• One-line docstring per test explaining what it validates and its exact purpose
• Inline comments only for non-obvious logic, complex expressions, or performance optimizations

Code Quality Requirements:

• PEP8 compliant, with no warnings
• Type hints used consistently where applicable
• No magic numbers — use named constants or fixtures
• Reusable fixtures using @pytest.fixture, with clear scope and side effects documented
• Use @pytest.mark.parametrize for repetitive tests, with clear parameterization
• Deterministic tests only (no randomness or external state, unless explicitly tracked in fixtures)
• No placeholders or TODOs — tests must be fully complete and executable
• No commented-out code — keep only the essential and relevant parts

Failure Modes:

• Expected failures noted and justified (e.g., tests that intentionally fail to demonstrate error handling)
• Failed tests with clear and actionable error messages

---

🔁 STEP 4 — Mock & Patch Setup
For every external dependency identified in Step 1:

#	Dependency	Mock Strategy	Patch Target	What's Being Isolated	Why Mocked	Mock Usage Example
1	...	...	...	...	...	...
...	...	...	...	...	...	...

Then provide:

• Complete mock/fixture setup code block, adhering to the provided naming conventions
• Explanation of WHY each dependency is mocked, including the risks it poses and the isolation benefits
• At least one example of how the mock is used in a test scenario
• Any side effects or additional setup required for the mock

Mocking Guidelines:

• Use unittest.mock.patch as a decorator or context manager
• Use MagicMock for objects, patch for functions/modules
• Use patch.multiple for multiple dependencies
• Use assert_mock_called and assert_mock_called_once_with for verifying mock interactions
• Do NOT mock the function under test or its pure logic — only external boundaries
• Mock dependencies at the highest level required to isolate the test
• Avoid mocking third-party libraries unless absolutely necessary

---

📊 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	Passed	Failed	Notes
Happy Path	...	...	...	...
Edge Cases	...	...	...	...
Exception Tests	...	...	...	...
Mock/Patch	...	...	...	...
Negative Inputs	...	...	...	...
Must Have	...	...	...	...
Should Have	...	...	...	...
Nice to Have	...	...	...	...

Quality Marker	Status	Count	Passed	Failed	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, code refactoring)
• Additional security, performance, or usability tests to consider
• Command to run the tests:
  pytest [filename] -v --tb=short --cov=path/to/module --cov-report=term-missing

---

Here is my Python code:

[PASTE YOUR CODE HERE]

Please generate the comprehensive test suite following the provided structure,