New Tests for Recent Work

Instructions

Step 1: Identify Recent Changes

git diff HEAD~1

git diff main...HEAD

• New functions, methods, or components
• Changed behavior in existing code
• New API endpoints or routes
• Modified business logic

Step 2: Audit Existing Coverage

• src/foo.ts

  → look for

  src/foo.test.ts

  ,

  tests/foo.test.ts

  ,

  __tests__/foo.test.ts

• Follow the project's test file convention

Step 3: Prioritize by Risk

1. Complex logic — conditionals, loops, state machines, calculations
2. Error paths — what happens when things fail
3. Data transformations — parsing, formatting, mapping
4. Integration boundaries — API calls, database queries, external services
5. User-facing behavior — things that break the experience if wrong

• Simple getters/setters
• Pure pass-through functions
• Framework boilerplate
• Code that's already well-covered

Step 4: Write Tests

• Name describes behavior, not implementation:

  "returns empty array when no results found"

  not

  "test getResults"

• Arrange-Act-Assert structure
• One behavior per test — if a test name has "and", split it
• Real edge cases: empty input, null/undefined, boundary values, concurrent access, error responses

Step 5: Verify

Step 6: Report

## New Test Coverage

**Files analyzed:** [count]
**Tests added:** [count]
**Potential bugs found:** [count, if any]

### Added
- `[test file]`: [what behaviors are now covered]

### Skipped (adequate coverage)
- `[file]`: already covered by [test file]

### Potential Bugs
- `[test name]`: expected [X] but got [Y] — [file:line]