---

name: scenario-testing description: This skill should be used when writing tests, validating features, or needing to verify code works. Triggers on "write tests", "add test coverage", "validate feature", "integration test", "end-to-end", "e2e test", "mock", "unit test". Enforces scenario-driven testing with real dependencies in .scratch/ directory.

Scenario-Driven Testing for AI Code Generation

Core Principle

The Iron Law: "NO FEATURE IS VALIDATED UNTIL A SCENARIO PASSES WITH REAL DEPENDENCIES"

Mocks create false confidence. Only scenarios exercising real systems validate that code works.

The Truth Hierarchy

1. Scenario tests (real system, real data) = truth
2. Unit tests (isolated) = human comfort only
3. Mocks = lies hiding bugs

As stated in the principle: "A test that uses mocks is not testing your system. It's testing your assumptions about how dependencies behave."

When to Use This Skill

• Validating new functionality
• Before declaring work complete
• When tempted to use mocks
• After fixing bugs requiring verification
• Any time you need to prove code works

Required Practices

1. Write Scenarios in .scratch/

• Use any language appropriate to the task
• Exercise the real system end-to-end
• Zero mocks allowed
• Must be in .gitignore (never commit)

2. Promote Patterns to scenarios.jsonl

• Extract recurring scenarios as documented specifications
• One JSON line per scenario
• Include: name, description, given/when/then, validates
• This file IS committed

3. Use Real Dependencies

External APIs must hit actual services (sandbox/test mode acceptable). Mocking any dependency invalidates the scenario.

4. Independence Requirement

Each scenario must run standalone without depending on prior executions. This enables:

• Parallel execution
• Prevents hidden ordering dependencies
• Reliable CI/CD integration

What Makes a Scenario Invalid

A scenario is invalid if it:

• Contains any mocks whatsoever
• Uses fake data instead of real storage
• Depends on another scenario running first
• Never actually executed to verify it passes

Common Violations to Avoid

Reject these rationalizations:

• "Just a quick unit test..." - Unit tests don't validate features
• "Too simple for end-to-end..." - Integration breaks simple things
• "I'll mock for speed..." - Speed doesn't matter if tests lie
• "I don't have API credentials..." - Ask your human partner for real ones

Definition of Done

A feature is complete only when:

1. ✅ A scenario in .scratch/ passes with zero mocks
2. ✅ Real dependencies are exercised
3. ✅ .scratch/ remains in .gitignore
4. ✅ Robust patterns extracted to scenarios.jsonl

Example Workflow

1. Write scenario - Create .scratch/test-user-registration.py
2. Use real dependencies - Hit real database, real auth service (test mode)
3. Run and verify - Execute scenario, confirm it passes
4. Extract pattern - Document in scenarios.jsonl
5. Keep .scratch ignored - Never commit scratch scenarios

Why This Matters

• Unit tests verify isolated logic
• Integration tests verify components work together
• Scenario tests verify the system actually works

Only scenario tests prove your feature delivers value to users.