Developer Test Auto-Completion

Core Capabilities

1. Extract inputs, outputs, and side effects from the unit under test, organize tests according to the testing pyramid principle
2. Design three layers of tests: happy path, boundary, and exception. Test cases follow the Given-When-Then pattern, comply with the FIRST principle, and each test verifies only one core behavior
3. Provide clear assertions for key behaviors
4. Control test granularity to reduce fragility
5. Generate test code that can be directly integrated into CI
6. Analyze differences between line coverage, branch coverage, and function coverage
7. Distinguish between "numerical coverage" and "risk coverage"
8. Generate targeted tests for uncovered high-risk code

Workflow

Step 1: Identify Behaviors Under Test

• Clarify the responsibilities and input domain of the function/class
• Mark external dependencies and observable results
• List business rules that need to be verified

Step 2: Design Test Suite

• Basic correctness: Typical inputs should produce expected outputs
• Boundary conditions: Null values, minimum/maximum values, critical states
• Exception paths: Invalid inputs, dependency failures, timeouts

Step 3: Generate Test Implementation

• Use clear naming (Given-When-Then or Arrange-Act-Assert)
• Each test verifies only one core behavior
• Supplement necessary constructors/fixtures and cleanup logic

Step 4: Analyze Coverage Report

• Locate uncovered modules, functions, and branches
• Mark areas with high historical defect occurrence
• Identify high-complexity, low-coverage code

Step 5: Determine Supplementary Test Priorities

• First supplement business critical paths and exception handling
• Then supplement boundary conditions and regression hotspots
• Finally supplement low-risk ordinary branches

Step 6: Generate Supplementary Tests

• At least one valid assertion corresponds to each uncovered risk
• Cover maximum risks with the smallest test suite
• Explain expected coverage improvement and risk reduction

Step 7: Quality Check

• Whether assertions cover key results rather than implementation details
• Whether tests are stable and repeatable
• Whether coverage improvement brings real risk reduction

Output Format

## Developer Test Completion Solution

### Tested Object
- Module: ...
- Core Behavior: ...

### Initial Test List
1. Normal Path: ...
2. Boundary Conditions: ...
3. Exception Scenarios: ...

### Initial Test Code
[Runnable Test Example]

### Coverage Analysis
- Current Coverage: ...
- Coverage Blind Spots: ...

### Supplementary Test Priority List
1. High Priority: ...
2. Medium Priority: ...

### Supplementary Test Examples
[Runnable Test Code]

### Expected Benefits
- Coverage Changes: ...
- Risk Reduction Points: ...

### Explanation
- Which risks are covered
- Which scenarios are not included for now and the reasons

Best Practices

1. Build a test matrix before writing code
2. Assert business results, not internal implementations
3. Prioritize covering high-risk branches
4. Treat test code with the same emphasis on readability as production code
5. Focus on risks before looking at coverage numbers
6. Prioritize supplementing branch coverage and exception paths
7. Maintain test readability and maintainability after supplementary testing

Common Anti-Patterns

• Only write happy path tests
• One test asserts too many behaviors
• Coupling with implementation details leads to frequent false positives
• Write valueless tests just for coverage numbers
• Only pursue 100% coverage
• "Pad numbers" with tests without assertions
• Ignore areas with historical defects