# Lisa Test Strategy

> Test strategy design. Coverage matrix, edge cases, TDD sequence planning, test quality review. Behavior-focused testing over implementation details.

- Skill: `codyswanngt/lisa-test-strategy` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add codyswanngt/lisa-test-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-test-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: codyswanngt (https://skillmd.com/u/codyswanngt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/codyswanngt/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:

```text
## 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