generate-test

What this skill does

# Generate Test Skill

Generate Vitest test files from `test-plan.md` by spawning qa-specialist agents that produce behavior-driven tests against Supabase local.

**All test files are generated in the root `tests/` directory** — NOT co-located with source code.

---

## When to Use

Use `/generate-test` when:
- You have a **test-plan.md** with test scenarios defined
- You want to generate **.test.ts** files for feature behavior, RLS policies, and constraints
- Tests should run against **Supabase local** (not UI, not browser)

Do NOT use when:
- You need UI/component tests (use @testing-library/react directly)
- You need E2E browser tests (use Playwright directly)
- No test-plan.md exists yet (create one first)

---

## Test Directory Structure

All generated test files go into the root `tests/` directory:

```
tests/
├── utils/
│   └── supabase.ts              # Shared Supabase test utilities
├── features/
│   ├── auth/
│   │   └── auth.test.ts         # Auth feature behavior tests
│   ├── orders/
│   │   └── orders.test.ts       # Orders feature behavior tests
│   └── users/
│       └── users.test.ts        # Users feature behavior tests
├── rls/
│   ├── users.test.ts            # Cross-feature RLS tests for users table
│   └── orders.test.ts           # Cross-feature RLS tests for orders table
└── constraints/
    ├── users.test.ts            # Constraint enforcement tests for users table
    └── orders.test.ts           # Constraint enforcement tests for orders table
```

---

## How It Works

```
/generate-test [scope]
      |
      v
+----------------------------------------------------------+
|  STEP 1: Get scope                                        |
|  - From argument: /generate-test auth                     |
|  - From argument: /generate-test all                      |
|  - OR from AskUserQuestion if not provided                |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 2: Read context                                     |
|  - test-plan.md (primary input — test scenarios)          |
|  - references/vitest-best-practices.md (testing rules)    |
|  - backend-plan.md (schema, RLS, constraints)             |
|  - vitest.config.ts (existing test configuration)         |
|  - Existing .test.ts files (patterns and conventions)     |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 3: Plan test file generation                        |
|  - Group scenarios by feature / test category             |
|  - Determine output file paths (root tests/ directory)    |
|  - Identify test categories per file:                     |
|    CRUD | RLS | Constraints | Edge Cases                  |
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 4: Spawn qa-specialist agents in PARALLEL           |
|                                                           |
|  ┌────────────────┐  ┌────────────────┐                   |
|  │ qa-specialist   │  │ qa-specialist   │                  |
|  │ Feature: auth   │  │ Feature: orders │                  |
|  │ → auth.test.ts  │  │ → orders.test.ts│                  |
|  └────────────────┘  └────────────────┘                   |
|                                                           |
|  One agent per feature/test-group — all run simultaneously|
+----------------------------------------------------------+
      |
      v
+----------------------------------------------------------+
|  STEP 5: Verify & report                                  |
|  - List all generated .test.ts files                      |
|  - Show test count per category                           |
|  - Suggest running: npx vitest run                        |
+----------------------------------------------------------+
```

---

## Step 1: Get Scope

### Option A: From arguments

If the user provides a scope:
```
/generate-test all           → Generate tests for ALL features in test-plan.md
/generate-test auth          → Generate tests for the auth feature only
/generate-test orders,users  → Generate tests for specific features
```

Extract the scope directly. **Do NOT ask questions — proceed to Step 2.**

### Option B: No argument provided

If the user invokes with no argument (`/generate-test`), you MUST use AskUserQuestion:

```
AskUserQuestion:
  question: "What scope of tests do you want to generate?"
  header: "Test Scope"
  options:
    - label: "All features (Recommended)"
      description: "Generate tests for every feature in test-plan.md"
    - label: "Specific feature"
      description: "I'll specify which feature(s) to test"
    - label: "RLS policies only"
      description: "Generate only RLS policy tests for all tables"
    - label: "CRUD only"
      description: "Generate only CRUD behavior tests"
```

If "Specific feature" is selected, follow up:

```
AskUserQuestion:
  question: "Which feature(s) should I generate tests for? (comma-separated)"
  header: "Features"
  options:
    - label: "I'll type it"
      description: "Let me specify the feature names"
```

### Question Rules
- Maximum **2 questions** to get the scope
- If arguments provided, ask **ZERO questions**
- Capture as `{test_scope}`

---

## Step 2: Read Context (MANDATORY)

### 2.1 Read test-plan.md (primary input)

```
Glob: **/test-plan.md OR **/test.plan.md
Read: [found path]
```

**If test-plan.md does NOT exist:**
> `test-plan.md` not found. Create a test plan first that defines test scenarios and acceptance criteria for each feature.

**STOP. Do NOT proceed.**

### 2.2 Read vitest best practices

```
Read: references/vitest-best-practices.md
```

Extract key rules to inject into agent prompts:
- AAA pattern, strict assertions, parameterized tests
- Test isolation, cleanup, async handling
- NEVER rules (no toBeTruthy, no shared state, no any)

### 2.3 Read backend context

```
Glob: **/backend-plan.md
Read: [found path] — schema definitions, RLS policies, constraints

Glob: **/dev-plan.md
Read: [found path] — feature context and business rules
```

### 2.4 Check existing test infrastructure

```
Glob: **/vitest.config.ts
Read: [found path] — check clearMocks, resetMocks, restoreMocks

Glob: tests/utils/** OR tests/setup.*
Read: [check for existing Supabase test helpers]

Glob: tests/**/*.test.ts
[List existing test files to understand patterns]
```

If vitest.config.ts is missing `clearMocks: true`, `resetMocks: true`, `restoreMocks: true`:

> **Warning:** Global mock cleanup is not configured. Recommend adding to vitest.config.ts:
> ```ts
> test: { clearMocks: true, resetMocks: true, restoreMocks: true }
> ```

### 2.5 Check for shared test utilities

```
Glob: tests/utils/supabase.ts
Read: [check if Supabase test client helpers already exist]
```

If NO shared test utilities exist, the first agent will generate them.

---

## Step 3: Plan Test File Generation

### 3.1 Ensure tests directory exists

```
Bash: mkdir -p tests/utils tests/features tests/rls tests/constraints
```

### 3.2 Parse test-plan.md

Extract test scenarios grouped by feature. For each feature, identify:
- **CRUD tests** — insert, select, update, delete operations
- **RLS tests** — access control per role (owner, other user, anon)
- **Constraint tests** — NOT NULL, UNIQUE, CHECK, FK violations
- **Edge case tests** — empty inputs, boundaries, concurrent operations

### 3.3 Determine output file paths

Map each feature/group to a test file in the root `tests/` directory:

| Test Category | Output Path |
|---------------|-------------|
| Feature behavior | `tests/features/{name}/{name}.test.ts` |
| Shared test utils | `tests/utils/supabase.ts` |
| Supabase RLS (cross-feature) | `tests/rls/{table}.test.ts` |
| Supabase constraints | `tests/constraints/{table}.test.ts` |

### 3.4 Filter by scope

```
IF tes