Test

---
name: afc:test
description: "Test strategy and writing — unit, integration, e2e tests, coverage improvement"
argument-hint: "[target: file path, feature name, or coverage]"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
model: sonnet
---

# /afc:test — Test Strategy Planning and Test Writing

> Establishes a test strategy for implemented code and writes tests.
> Standalone command — not part of the auto pipeline. Use after implement or before review.

## Arguments

- `$ARGUMENTS` — (required) Test target. One of:
  - File path or directory (e.g., `src/features/auth/`)
  - Feature name (e.g., `login flow`)
  - `coverage` — full coverage analysis and gap remediation

## Project Config (auto-loaded)

!`cat .claude/afc.config.md 2>/dev/null || echo "[CONFIG NOT FOUND] .claude/afc.config.md not found. Create it with /afc:init."`

Values used: `{config.gate}` (CI), `{config.architecture}` (layers), test framework from Project Context.

## Execution Steps

### 1. Target Analysis

1. Parse `$ARGUMENTS`:
   - **File/Directory** → read that code, check for existing test files
   - **Feature name** → explore related files, read code
   - **coverage** → scan all existing tests, identify coverage gaps

2. **Existing coverage check**: Before writing new tests, evaluate what already exists:
   - Are there existing test files for the target? What do they cover?
   - If existing tests already provide adequate coverage → report: "Existing tests in {path} already cover the core scenarios. No additional tests needed." Ask user: "(1) Add edge case tests only (2) Rewrite tests (3) Abort"
   - If partially covered → identify specific gaps and target only those

3. Determine characteristics of target code:
   - Public interface (function signatures, component props)
   - Dependencies (external APIs, DB, state management)
   - Branch points (conditionals, error handling)
   - Edge cases

### 2. Test Strategy Planning

```markdown
### Test Strategy
- Target: {file/feature}
- Framework: {test framework from Project Context}
- Test types:
  - [ ] Unit tests: {list of target functions/methods}
  - [ ] Integration tests: {component interactions}
  - [ ] E2E tests: {user scenarios} (only if applicable)
- Mocking strategy: {mocking approach per dependency}
```

Confirm strategy with user before proceeding.

### 3. Write Tests

**Principles:**
- **AAA pattern**: Arrange → Act → Assert
- **Test names**: `it('should {expected behavior} when {condition}')` format
- **Independence**: each test can run independently
- **Readability**: test code serves as documentation

**Priority:**
1. Happy path (normal behavior)
2. Error cases (error handling)
3. Edge cases (boundary values)
4. Regression guards (prevent bug recurrence)

**Test file location**: follows project convention
- Co-location: `{filename}.test.{ext}` (same directory)
- Separate: `__tests__/{filename}.test.{ext}` or `tests/` directory

### 4. Critic Loop

> **Always** read `${CLAUDE_SKILL_DIR}/../../docs/critic-loop-rules.md` first and follow it.

Run the critic loop until convergence. Safety cap: 5 passes.

| Criterion | Validation |
|-----------|------------|
| **COVERAGE** | Are all core logic and branch points covered? |
| **QUALITY** | Do tests validate behavior, not implementation details? Are there any brittle tests? |

Follow verdict handling and output format per `docs/critic-loop-rules.md`.

### 5. Run and Verify Tests

```bash
{config.gate}
```

On failure:
1. Determine whether the issue is in test code or implementation code
2. Test code issue → fix tests
3. Implementation code issue → report to user (test found a bug)

Maximum 3 retries.

### 6. Final Output

```
Tests complete
├─ Target: {file/feature}
├─ Written: {N} tests ({unit X, integration Y, E2E Z})
├─ Coverage: {summary of key branch point coverage}
├─ Critic: converged ({N} passes, {M} fixes, {E} escalations)
├─ Verified: all tests passing
└─ Found: {bug details if found, otherwise "no issues"}
```

## Notes

- **No implementation coupling**: test external behavior, not internal implementation. Do not directly test private methods.
- **Minimize mocking**: mock only necessary external dependencies. Excessive mocking reduces test value.
- **Avoid snapshot overuse**: UI snapshots for core structure only. Avoid snapshots that break on style changes.
- **Respect existing tests**: follow existing test patterns and conventions. Confirm with user before introducing new patterns.