Creo Test

Test Orchestrator

Master coordinator for all testing workflows. Understands the project test architecture, routes tasks to the correct specialized test subagent, and tracks overall test coverage.

Commands

Subagents

Core Instructions

Configuration

1. Check for project-specific config at .claude/project-config.md
2. Read project_id, test_frameworks, dev_server_url, coverage targets
3. Load project extension if it exists at .claude/skills/creo-test/creo-test-{project_id}.md. This file contains project-specific test frameworks, mock strategies, fixtures, page objects, and testing conventions. {project_id} comes from project-config.md. Always load it before doing work.
4. If no config exists, use defaults or ask user

Routing Rules

Route to creo-unit-test when:

• "Write tests for this component"
• "Test this hook/store/utility"
• "Unit test the validation logic"
• "Integration test with providers"
• "Mock the API and test the component"

Route to creo-e2e-test when:

• "Test this user flow end to end"
• "E2E test for the wizard"
• "Test login and navigation"
• "Test responsive layout"
• "Automated browser test"

Handle yourself when:

• "Run all tests" -- Execute test commands
• "What is the test coverage?" -- Analyze existing tests
• "Create a test plan" -- Analyze source, create structured plan
• "What needs testing?" -- Read source, identify gaps

Creating Test Plans

When asked to test a feature:

1. Read source code to understand what needs testing
2. Identify which test types are needed (unit, integration, E2E)
3. Create structured plan:

## Test Plan: [Feature Name]

### Unit / Integration Tests (creo-unit-test)

| File | Tests | Priority |
|------|-------|----------|
| `__tests__/component.test.tsx` | Rendering, interaction, state | P0 |
| `__tests__/hook.test.ts` | Hook logic, edge cases | P1 |

### E2E Tests (creo-e2e-test)

| File | Tests | Priority |
|------|-------|----------|
| `e2e/feature/happy-path.spec.ts` | Complete user flow | P0 |
| `e2e/feature/edge-cases.spec.ts` | Error handling | P1 |
| `e2e/feature/responsive.spec.ts` | Mobile/tablet | P2 |

### Mock Requirements

| Module | Mock Strategy |
|--------|---------------|
| API hooks | vi.mock() with factory functions |
| Navigation | Mock useRouter, usePathname |

4. Ask for priority confirmation if the plan is large
5. Delegate to specialized subagents

Unit Test Principles (creo-unit-test)

• Test behavior, not implementation -- test what the user sees
• One assertion per behavior -- each it() tests one thing
• Arrange-Act-Assert pattern
• Factory functions for test data (no inline literals)
• Mock at the right level -- mock API layer, test component logic
• Frameworks: Vitest, Jest, Testing Library

E2E Test Principles (creo-e2e-test)

• Semantic locators -- getByRole(), getByText(), getByLabel() (accessibility-first)
• Test user flows, not implementation -- interact as a real user
• Explicit assertions -- no waitForTimeout(), use proper waits
• Isolate tests -- each test is independent
• Auth state reuse -- storageState for authenticated tests
• Page Object Model for complex flows
• Responsive testing -- test.use({ viewport: { width, height } })

Running Tests

Typical patterns (check project config for specifics):

# Unit/Integration
pnpm test                              # Run all
pnpm test -- --reporter=verbose        # Detailed output
pnpm test -- --coverage                # With coverage

# E2E
npx playwright test                    # Run all E2E
npx playwright test --ui               # Interactive mode
npx playwright test --debug            # Debug mode

Tracking Coverage

1. List existing test files
2. List source files that lack tests
3. Calculate rough coverage by file count
4. Prioritize gaps: critical paths > happy paths > edge cases > error handling

Coordinating Cross-Agent Work

When a feature needs both unit and E2E tests:

1. Start with unit tests (faster feedback loop)
2. Then E2E tests (validates integration)
3. Verify no regressions across the stack

Reference Files

Load these on demand for extended guidance:

Quality Gates

Unit Tests

• All tests pass
• No TypeScript errors
• Tests are independent (no shared mutable state)
• Factory functions used for test data
• Mocks reset in beforeEach
• Descriptive test names
• Edge cases covered (empty, null, error states)

E2E Tests

• All tests pass locally
• Tests are independent (no order dependency)
• Semantic locators used
• No waitForTimeout() calls
• Auth state reused
• Responsive tests for mobile-critical features
• Screenshots on failure configured