OpenAgentsControl test-generation
Use when the user asks for tests, mentions TDD, or when new code has been written and needs test coverage.
git clone https://github.com/darrenhinde/OpenAgentsControl
T=$(mktemp -d) && git clone --depth=1 https://github.com/darrenhinde/OpenAgentsControl "$T" && mkdir -p ~/.claude/skills && cp -r "$T/plugins/claude-code/skills/test-generation" ~/.claude/skills/darrenhinde-openagentscontrol-test-generation && rm -rf "$T"
plugins/claude-code/skills/test-generation/SKILL.mdTest Generation
Overview
Generate comprehensive tests following TDD principles and project testing standards. Runs in isolated test-engineer context with pre-loaded testing conventions.
Announce at start: "I'm using the test-generation skill to create tests for [feature/component]."
The Process
Step 1: Specify Test Requirements
Provide clear requirements to test-engineer:
/test-generation Feature: JWT token validation middleware Behaviors: 1. Valid token → allow request 2. Expired token → reject with 401 3. Invalid signature → reject with 401 4. Missing token → reject with 401 Coverage: All critical paths Testing Standards (pre-loaded): - Framework: vitest - Mocks: vi.mock() - Structure: AAA pattern
Step 2: Review Test Plan
Test-engineer proposes a test plan:
## Test Plan Behaviors: 1. Valid token - ✅ Positive: Allow request with valid JWT - ❌ Negative: Reject malformed JWT 2. Expired token - ✅ Positive: Normal token works - ❌ Negative: Expired token rejected with 401 Mocking Strategy: - JWT verification: Mock with vi.mock() - Request/Response: Use test doubles Coverage Target: 95% line coverage, all critical paths
IMPORTANT: Review and approve before implementation proceeds.
Step 3: Implement Tests
Test-engineer implements following AAA pattern (Arrange-Act-Assert):
describe('JWT Middleware', () => { it('allows request with valid token', () => { // Arrange const req = mockRequest({ headers: { authorization: 'Bearer valid.jwt.token' } }); // Act const result = jwtMiddleware(req); // Assert expect(result.authorized).toBe(true); }); });
Step 4: Run Self-Review
Test-engineer verifies:
- ✅ Positive AND negative tests for each behavior
- ✅ AAA pattern followed
- ✅ All external dependencies mocked
- ✅ Tests are deterministic (no flakiness)
- ✅ Standards compliance
Step 5: Run Tests
Execute test suite and verify all pass:
npm test -- jwt.middleware.test.ts
Step 6: Return Results
status: success tests_written: 8 coverage: lines: 96% branches: 93% functions: 100% behaviors_tested: - name: "Valid token handling" positive_tests: 2 negative_tests: 2 test_results: passed: 8 failed: 0 deliverables: - "src/auth/jwt.middleware.test.ts"
TDD Workflow
For test-driven development, invoke BEFORE implementation:
/test-generation Write tests for user registration endpoint (not yet implemented): Expected Behavior: - POST /api/register with valid data → 201 + user object - POST /api/register with duplicate email → 409 error - POST /api/register with invalid email → 400 error Note: Implementation does not exist. Write tests that define expected behavior.
Tests will fail initially—use them as spec to guide implementation.
Error Handling
Tests don't match project conventions:
- Main agent must pre-load
.opencode/context/core/standards/tests.md
Missing edge cases:
- Specify explicitly in requirements
Flaky tests:
- Ensure all external dependencies mocked
Red Flags
If you think any of these, STOP and re-read this skill:
- "The implementation is simple enough that tests aren't needed"
- "I'll just write the happy path tests for now"
- "Mocking is too complex for this dependency"
- "I'll add tests after the feature is stable"
Common Rationalizations
| Excuse | Reality |
|---|---|
| "It's too simple to break" | Simple code breaks in simple ways. Tests document the contract, not just catch bugs. |
| "Negative tests are obvious failures, not worth writing" | Negative tests are where bugs hide. "Obviously fails" is not the same as "correctly fails". |
| "Mocking this dependency is too hard" | Hard-to-mock dependencies are a design smell. Mock them anyway and note the smell. |
| "Tests slow down delivery" | Tests without negative cases give false confidence. False confidence slows delivery more. |
Remember
- Pre-load testing standards BEFORE invoking skill
- Specify clear behaviors and acceptance criteria
- Review test plan before implementation
- Both positive AND negative tests required
- All external dependencies MUST be mocked (no real network/DB calls)
- AAA pattern (Arrange-Act-Assert) mandatory
- Tests must be deterministic (no randomness or time dependencies)
Related
- code-execution
- code-review
- context-discovery