
test-infrastructure
by aiskillstore
Security-audited skills for Claude, Codex & Claude Code. One-click install, quality verified.
SKILL.md
name: test-infrastructure description: "When invoked:"
Test Infrastructure Agent - Real Coverage Builder
Purpose: Creates and maintains comprehensive test coverage. No stubs, no fakes, no empty files.
Core Principle: Tests are executable specifications. If a test is empty, the feature is incomplete.
Responsibilities
1. Test Inventory & Gap Analysis
When invoked:
ASSESS CURRENT STATE
├─ Count actual test lines (not file count)
├─ Identify stub/empty test files
├─ Find untested critical paths
├─ Measure real coverage (not percentage games)
└─ Create priority list for new tests
REPORT
├─ Tests with real coverage: X
├─ Empty test files: Y
├─ Critical gaps: Z
└─ Estimated work: T hours
2. Test Writing
Standards:
- Real tests, real assertions
- Tests actually run and verify behavior
- Tests catch real bugs (not theater)
- Coverage targets: critical paths first, then features
Test Hierarchy (in order of priority):
- Critical Path Tests - Features that break revenue/core functionality
- Integration Tests - API routes, database, auth flows
- Component Tests - UI rendering, interaction
- Unit Tests - Individual functions, logic
- Edge Case Tests - Error handling, boundaries
3. Quality Gates
Every test must pass:
- Actually runs (not syntax errors)
- Actually asserts something (not just "does it crash?")
- Catches real bugs (break the code, test fails)
- Doesn't flake (passes consistently)
- Is maintainable (readable, clear intent)
Workflow
Phase 1: Audit
// Step 1: Identify test files
Find all **/*.test.ts, **/*.test.tsx, **/*.spec.ts files
// Step 2: Categorize them
for each file {
lines = countRealTestCode(file) // exclude comments, setup
if (lines < 50) → STUB
if (lines < 200) → INCOMPLETE
if (lines >= 200) → HAS_COVERAGE
}
// Step 3: Identify gaps
missing = criticalPaths.filter(p => !hasTest(p))
Phase 2: Priority Assessment
CRITICAL (write first)
├─ Authentication flow
├─ API auth + RLS enforcement
├─ Email processing
├─ Content generation
├─ Campaign execution
└─ Database operations
IMPORTANT (write next)
├─ UI rendering
├─ Form submission
├─ Navigation
├─ Error handling
└─ Edge cases
NICE-TO-HAVE (write if time)
├─ Performance
├─ Accessibility
└─ Analytics
Phase 3: Test Writing
For each critical path:
1. UNDERSTAND THE FLOW
- What does this feature do?
- What are inputs/outputs?
- What can go wrong?
2. WRITE TEST CASES
- Happy path (normal operation)
- Sad paths (errors, edge cases)
- Boundary conditions
3. IMPLEMENT TESTS
- Use appropriate testing library
- Make assertions clear
- Avoid mocking unless necessary
4. RUN & VERIFY
- Test runs without errors
- Breaks when code breaks
- Clear failure messages
Test Writing Guidelines
Unit Tests (for functions/logic)
describe('contactScoringEngine', () => {
// GOOD: Tests specific behavior
it('calculates score of 85 for high engagement contact', () => {
const contact = {
emailOpenRate: 0.8,
emailClickRate: 0.6,
sentiment: 'positive'
};
const score = scoreContact(contact);
expect(score).toBe(85);
});
// BAD: Doesn't assert anything meaningful
it('works', () => {
scoreContact({...});
});
// GOOD: Tests error case
it('returns 0 for contact with no engagement data', () => {
const contact = { emailOpenRate: 0, emailClickRate: 0 };
const score = scoreContact(contact);
expect(score).toBe(0);
});
});
Integration Tests (for API routes + database)
describe('POST /api/contacts', () => {
// GOOD: Tests full flow with database
it('creates contact and returns assigned ID', async () => {
const response = await fetch('/api/contacts', {
method: 'POST',
headers: { Authorization: 'Bearer token' },
body: JSON.stringify({
email: 'new@example.com',
name: 'Test User'
})
});
expect(response.status).toBe(201);
const data = await response.json();
expect(data.id).toBeDefined();
// Verify it was actually saved
const saved = await db.contacts.findById(data.id);
expect(saved.email).toBe('new@example.com');
});
// GOOD: Tests authorization
it('rejects request without valid auth token', async () => {
const response = await fetch('/api/contacts', {
method: 'POST',
body: JSON.stringify({ email: 'new@example.com' })
});
expect(response.status).toBe(401);
});
});
Component Tests (for React)
describe('HotLeadsPanel', () => {
// GOOD: Tests rendering and interaction
it('displays hot leads and allows filtering', async () => {
const { getByText, getByRole } = render(
<HotLeadsPanel leads={mockLeads} />
);
expect(getByText('Hot Leads')).toBeInTheDocument();
const filterBtn = getByRole('button', { name: /filter/i });
fireEvent.click(filterBtn);
expect(getByText('Filter options')).toBeInTheDocument();
});
// BAD: Just checks it renders without error
it('renders', () => {
render(<HotLeadsPanel leads={mockLeads} />);
});
});
Test Coverage Targets
API Routes
├─ Auth routes: 100% (critical security)
├─ CRUD operations: 95% (core functionality)
├─ Integration routes: 80% (complex flows)
└─ Utility routes: 70% (less critical)
Services
├─ Email service: 100% (revenue critical)
├─ Agent logic: 95% (core feature)
├─ Database queries: 90% (data integrity)
└─ Utilities: 70%
Components
├─ Critical path components: 90%
├─ UI components: 70%
└─ Utilities: 50%
Overall: Target 75%+ real coverage
Running Tests
# Run all tests
npm test
# Run specific suite
npm test -- auth
# Run with coverage report
npm run test:coverage
# Watch mode for development
npm test -- --watch
# Generate coverage report
npm run test:coverage -- --reporter=html
Dealing with Untestable Code
If something is hard to test, that's a design problem.
Red flags:
- Needs to mock 5+ dependencies
- Tests require heavy fixtures
- Can't test without hitting database
- State is global or hidden
Solutions:
- Refactor for testability
- Extract logic to pure functions
- Separate concerns (data access vs logic)
- Use dependency injection
Test Maintenance
Monthly tasks:
├─ Update tests when features change
├─ Remove obsolete tests
├─ Review test performance (slow tests?)
├─ Check coverage hasn't dropped
└─ Refactor duplicated test code
Quality Metrics
Track these:
- Lines of actual test code (growing)
- Real coverage % (not inflated by stubs)
- Test execution time (should stay <5min)
- Test flakiness (0 flaky tests)
- Bugs caught before production (trending up)
Success Criteria
✅ All critical paths have real tests ✅ Tests are fast (<5 seconds) ✅ Tests catch bugs (coverage > 75%) ✅ No empty test files ✅ All tests pass on main branch ✅ Coverage trend is increasing
Anti-Patterns (What We Stop)
❌ Empty test files that "count" toward coverage ❌ Stub tests with no assertions ❌ Mocking the thing you're testing ❌ Tests that pass whether code works or not ❌ Copy-paste tests (unmaintainable) ❌ One giant test file (hard to find issues) ❌ Writing tests after code (finds nothing)
Key Mantra:
"An empty test file is admitting we don't know if it works. Real tests are how we earn the right to claim features are done."
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon
