Test Generation

---
name: test-generation
description: Use when generating test files for existing code or from a spec — language-agnostic, works with any test framework. Triggers on "generate tests", "write tests for", "生成测试", "生成测试代码", "补测试".
---

# Test Generation (Language-Agnostic)

Generate anti-pattern-free test code from PRD acceptance criteria and source
code. Read inputs, produce test files. No execution, no reports, no source
modifications.

**Input:** PRD acceptance criteria + architecture docs + source code

## When to use

- Generating tests for a feature or bugfix
- Creating tests from a PRD, API contract, or existing source
- Triggers on "generate tests", "write tests for", "生成测试", "生成测试代码", "补测试"

**Not for:** the TDD red-green-refactor loop (use `tdd`); API contract testing (use `api-testing`); browser E2E flows (use `e2e-testing`).

## Steps

### 1. Detect language & framework

Scan the project before generating. Detection priority: existing test files
(naming conventions) → dependency manifests → test config files. If nothing
found, ask which framework to use.

- Load [references/language-patterns.md](references/language-patterns.md) for the per-language detection table (manifests and test-file patterns to scan for) and the Test Framework | Assertion Style | Mock Library mapping (testify/gomock, pytest/unittest.mock, jest/jest.fn, etc.)

### 2. Read inputs

Ask for or discover: PRD path (default `docs/PRD.md` or `docs/vX.Y/prd.md`), architecture docs
(default `docs/TECH.md` or `docs/vX.Y/tech.md`), source code to test (default `src/`), and the
auto-detected language/framework. Ask only critical questions before proceeding.

### 3. Extract testable conditions

- Per acceptance criterion → one or more test cases
- Per API endpoint / function signature → contract tests
- Per defined error state → error path test
- Per security-sensitive input → injection test (SQL, command, path traversal, XSS)

```
PRD: "US-001: User login"
AC: "Valid credentials return an authenticated session"
AC: "Invalid credentials return an error"
AC: "Empty fields show validation errors"

→ Test cases:
  1. valid credentials → success + session established
  2. wrong password → error response + message present
  3. empty email → validation error for email field
  4. empty password → validation error for password field
```

### 4. Generate test files

Write anti-pattern-free test code to the correct test directories. Every file
starts with a comment linking to requirements:

```
// Generated from: docs/PRD.md, US-001: User login
// Acceptance criteria: valid login, invalid credentials, empty fields
```

Adapt the comment syntax to the language (`#`, `//`, `/* */`, `--`).

## Coverage rules

Every generated test file covers these dimensions:

| Category | What to test | Anti-pattern to avoid |
|----------|-------------|----------------------|
| **Happy path** | Expected input → expected output | Don't mock the function under test |
| **Validation** | Invalid/missing fields → proper errors | Assert real error, not mock call |
| **Edge cases** | Boundary values, empty, null, very large | Don't mock out validation logic |
| **Error states** | Timeout, unavailable, 5xx | Mock at network/IO level, not error handler |
| **Security** | Injection patterns, auth bypass | Test real sanitization, not mock sanitizer |

### Mocking rules

**Mock only at external boundaries:** network, filesystem, clock, third-party
APIs. **Never mock:**

- The function/class under test itself
- Internal helpers that are fast and side-effect-free
- When mock setup would exceed 50% of the test body (use an integration test)
- When unsure of the dependency chain (run with real implementation first)

**Completeness rule:** when mocking an API response or data structure, include
ALL fields the real implementation returns — not just the fields the immediate
test touches. Partial mocks hide structural assumptions and fail silently.

## Integration tests are not optional

Always generate integration tests alongside unit tests for features that span
multiple components. Integration tests:

- Use fewer (or zero) mocks — wire real components together
- Verify the system behaves correctly end-to-end
- Use language-idiomatic file naming

```
Source: src/auth/login.go
  → Unit: src/auth/login_test.go
  → Integration: tests/integration/auth_login_test.go
```

## Generator decision matrix

| Input has | Generate |
|-----------|----------|
| User story + AC | Unit tests per AC + integration test for the story |
| API contract + schema | Contract / integration tests per endpoint |
| Source code without AC | Unit tests for public API surface |
| Error states in contract | Error path tests covering every defined error |
| Security-sensitive inputs | Injection tests (SQL, command, path traversal, XSS) |
| Database operations | Transaction/rollback tests |
| Auth-protected endpoints | Unauthenticated + forbidden tests |

**Output:** Complete test files (unit + integration) — code, not a report.

## Verify

- [ ] Language and framework auto-detected (not defaulted blindly)
- [ ] Every acceptance criterion has a matching test case
- [ ] Happy path, validation, edge cases, and error states covered per feature
- [ ] Both unit AND integration tests generated for multi-component features
- [ ] Mocks mirror the complete real data structure — no partial mocks
- [ ] Every test file has a source comment linking to requirements
- [ ] No test-only methods added to production classes
- [ ] No assertions solely on mock behavior or call counts

## References

- [${CLAUDE_PLUGIN_ROOT}/references/engineering-principles.md](${CLAUDE_PLUGIN_ROOT}/references/engineering-principles.md) — discipline every skill shares
- [${CLAUDE_PLUGIN_ROOT}/references/clean-code.md](${CLAUDE_PLUGIN_ROOT}/references/clean-code.md) — clean code principles for test quality
- [references/language-patterns.md](references/language-patterns.md) — per-language Test Framework | Assertion Style | Mock Library mapping