int2t05 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 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 — discipline every skill shares
- ${CLAUDE_PLUGIN_ROOT}/references/clean-code.md — clean code principles for test quality
- references/language-patterns.md — per-language Test Framework | Assertion Style | Mock Library mapping