Add Test Coverage

Add Test Coverage

Analyze the most recent commit (HEAD) and implement all tests required to cover new and modified code.

When to Use This Skill

• After completing a feature or fix, to ensure adequate test coverage before merge
• When a commit introduces new functions, methods, or API endpoints
• When modifying existing behavior that may not have sufficient tests
• During code review when test coverage gaps are identified

Workflow

Phase 1: Change Analysis

1. Identify changes in the latest commit:
   • Diff HEAD against its parent (HEAD~1), or against the appropriate base branch if more accurate
2. Classify each changed file by type based on file extensions and project structure:
   • Backend code (e.g., .go, .py, .java, .rb)
   • Frontend code (e.g., .js, .ts, .jsx, .tsx, .vue, .svelte)
   • Integration/API surfaces (e.g., handlers, controllers, routes)
   • Config, infrastructure, or test-only changes
3. For each changed area, determine:
   • What behavior was added or modified
   • Which existing tests (if any) already cover this behavior
   • Where new or expanded tests are needed

Phase 2: Test Plan Design

Draft a concrete test plan for this commit:

1. Scenarios to cover:

   • List specific behaviors that need tests
   • Identify edge cases and error conditions

2. Test layers to use:

   • Unit tests for individual functions/methods
   • Integration tests for cross-component behavior
   • E2E tests for user-visible flows (if applicable)

3. Test dependencies:

   • Required fixtures, mocks, or test data
   • Any setup/teardown requirements

4. Prioritization criteria:

   • Safety-critical paths
   • Public/externally visible behavior
   • Complex logic and branching
   • Previously under-tested areas

Phase 3: Test Implementation

Implement the tests specified in your plan:

1. Follow existing conventions:

   • Use existing test directories and naming patterns
   • Reuse shared test utilities and helpers
   • Match the style of existing tests in the repository

2. Test quality standards:

   • Each test should be focused on a single behavior
   • Tests must be deterministic (no flaky tests)
   • Tests should be readable and self-documenting
   • Include clear assertion messages

Phase 4: Execution and Refinement

1. Incremental testing:

   • Run only the relevant tests while developing
   • Use focused test commands (specific packages, files, or test names)

2. Validation:

   • Once confident, run a broader test subset to check for regressions
   • Ensure all new tests pass consistently

3. Failure diagnosis:

   • If tests fail, prefer fixing implementation bugs exposed by the tests
   • Only adjust tests when they don't match the correct intended behavior

Phase 5: Summary

Produce a concise summary including:

• Which files changed in the commit
• What tests were added or modified (by file and purpose)
• What behaviors are now covered that were not before
• The exact commands to run the relevant test suites

Constraints

• Do not remove or disable existing tests unless clearly invalid; explain any such changes
• Do not introduce new frameworks or major structural changes; work within the existing test stack
• Keep changes tightly scoped to covering the latest commit's behavior, not the entire repository

Examples

Example: New HTTP Handler in Go

Commit changes: Added internal/api/users.go with a CreateUser handler

Phase 1 output:

Changed files:
- internal/api/users.go (new file)
  - Added CreateUser handler
  - Added userRequest/userResponse types
  - Added input validation logic

Existing test coverage: None (new file)

Phase 2 output:

Test Plan:
1. Unit tests for input validation
   - Valid request succeeds
   - Missing required fields return 400
   - Invalid email format returns 400
2. Integration tests for CreateUser handler
   - Successful user creation returns 201
   - Duplicate email returns 409
   - Database error returns 500
3. Mocks needed: UserRepository interface

Phase 3 output:

Created: internal/api/users_test.go
- TestCreateUser_Success
- TestCreateUser_MissingFields
- TestCreateUser_InvalidEmail
- TestCreateUser_DuplicateEmail
- TestCreateUser_DatabaseError

Phase 5 summary:

Files changed in commit: internal/api/users.go

Tests added:
- internal/api/users_test.go (5 tests covering CreateUser handler)

New coverage:
- Input validation for user creation requests
- Success and error paths for CreateUser handler
- Database error handling

Run tests: go test ./internal/api/... -v

Begin by performing the diff-based analysis for HEAD and drafting the test plan before writing or modifying any tests.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.