Lisa Test Strategy

Test Strategy

Design test strategies, write tests, and review test quality.

Analysis Process

1. Read existing tests -- understand the project's test conventions (describe/it structure, naming, helpers)
2. Identify test types needed -- unit, integration, E2E based on the scope of changes
3. Map edge cases -- boundary values, empty inputs, error states, concurrency scenarios
4. For frontend scope, start from the behavior contract -- read the project's Gherkin scenarios and coverage map, identify which scenario IDs this work adds or changes, and treat each required scenario-platform obligation as a strategy line item per the bdd-e2e-coverage rule
5. Check coverage gaps -- run existing tests to understand current coverage of affected files
6. Design verification commands -- proof commands that empirically demonstrate the code works

Test Writing Process

1. Analyze the source file to understand its functionality
2. Identify untested code paths, edge cases, and error conditions
3. Write comprehensive, meaningful tests (not just coverage padding)
4. Follow the project's existing test patterns and conventions
5. Ensure tests are readable and maintainable

Output Format

Structure findings as:

## Test Analysis

### Test Matrix
| Component | Test Type | What to Test | Priority |
|-----------|-----------|-------------|----------|

### Edge Cases
- [edge case] -- why it matters

### Coverage Targets
- `path/to/file.ts` -- current: X%, target: Y%

### Test Patterns (from codebase)
- Pattern: [description] -- found in `path/to/test.spec.ts`

### Verification Commands
| Task | Proof Command | Expected Output |
|------|--------------|-----------------|

### TDD Sequence
1. [first test to write] -- covers [behavior]
2. [second test] -- covers [behavior]

Rules

• Always run bun run test to understand current test state before recommending or writing new tests
• Match existing test conventions -- do not introduce new test patterns
• For frontend work, the strategy is not complete until every required scenario-platform obligation has aligned e2e automation in the project's configured runner for that platform, or a dated waiver naming the runner limitation (bdd-e2e-coverage). A unit test, a route boot, or a passing test on a different platform never seals an obligation
• For work that adds or changes persistent state, the strategy is not complete until each new entity is classified in the project's state contract and anything fixture-owned has a sweep, per the reset-seed-coverage rule. Per-flow self-cleanup is not a strategy: a flow that deletes what it created only on its happy path leaks on every failure in between, which is how state pollution becomes an unreproducible flake months later
• Every test must have a clear "why" -- no tests for testing's sake
• Focus on testing behavior, not implementation details
• Verification commands must be runnable locally (no CI/CD dependencies)
• Prioritize tests that catch regressions over tests that verify happy paths
• Write comprehensive tests, not just coverage padding