/test-scaffolding

name: test-scaffolding
description: Automatically generate test scaffolding when user writes new code without tests or mentions needing tests. Supports unit, integration, e2e, and data tests for PHP and JavaScript. Invoke when user mentions "tests", "testing", "coverage", "write tests", or shows new untested code.

Test Scaffolding Generator

Automatically generate test scaffolding for untested code.

Testing Philosophy

Good tests are an investment, not a cost.

Core Beliefs

1. **Tests as Documentation**: Tests show how code should be used 2. **Fast Feedback**: Quick tests enable rapid development 3. **Confidence to Refactor**: Good test coverage allows safe changes 4. **Regression Prevention**: Tests catch bugs before production

Scope Balance

• **Quick scaffolding** (this skill): Fast test generation for single classes/functions
• **Comprehensive suites** (`/test-generate` command): Full project test coverage with test plans
• **Manual refinement**: Human review adds edge cases and business logic validation (essential for quality)

This skill provides rapid test scaffolding. For complete coverage, use comprehensive test generation + manual refinement.

When to Use This Skill

Activate this skill when the user:

• Shows new code and says "I need tests for this"
• Asks "how do I test this?"
• Mentions "no tests yet" or "untested code"
• Says "I should write tests" or "need test coverage"
• Shows a class/function and asks about testing
• Mentions specific test types: "unit test", "integration test", "e2e test"

Decision Framework

Before generating test scaffolding, determine:

What Type of Code Is This?

1. **Business logic function** → Unit test (fast, isolated) 2. **Class with dependencies** → Unit test with mocks/stubs 3. **API endpoint** → Integration test (test with real dependencies) 4. **UI component** → Component test (render, interactions) 5. **User flow** → E2E test (full browser simulation)

What Test Framework?

**PHP** (Drupal/WordPress):

• PHPUnit for unit and integration tests
• Drupal Kernel tests for module testing
• WordPress test framework for plugins/themes

**JavaScript**:

• Jest for unit and component tests
• Cypress for E2E tests
• React Testing Library for React components

What Should Be Tested?

**Unit tests (highest priority)**:

• ✅ **Happy path** - Expected behavior with valid input
• ✅ **Edge cases** - Boundary conditions (empty, null, zero, max)
• ✅ **Error handling** - Invalid input, exceptions
• ✅ **Business logic** - Calculations, transformations, decisions

**Don't test** (waste of time):

• ❌ Framework code (it's already tested)
• ❌ Simple getters/setters (no logic)
• ❌ Third-party libraries (trust their tests)

What Dependencies Need Mocking?

**Mock/stub**:

• ✅ External APIs (use fixtures instead)
• ✅ Database queries (use test database or mocks)
• ✅ File system operations (use virtual filesystem)
• ✅ Time-dependent code (mock date/time)

**Don't mock**:

• ❌ Code under test
• ❌ Simple data structures
• ❌ Pure functions

What Test Coverage Is Appropriate?

**Critical code** (90%+ coverage target):

• Authentication/authorization
• Payment processing
• Data writes/deletes
• Security-sensitive operations

**Standard code** (70-80% coverage target):

• Business logic
• API endpoints
• Public interfaces

**Low priority** (minimal coverage ok):

• Getters/setters
• Configuration
• UI styling

What Test Structure?

**AAA pattern** (standard): 1. **Arrange** - Set up test data and mocks 2. **Act** - Execute the code under test 3. **Assert** - Verify expected outcomes

**Test name convention**:

• `test_methodName_scenario_expectedBehavior()`
• Example: `test_calculateTotal_withDiscount_returnsReducedPrice()`

Decision Tree

User requests tests for code
    ↓
Analyze code type (function/class/endpoint/UI)
    ↓
Determine test type (unit/integration/e2e)
    ↓
Identify framework (PHPUnit/Jest/Cypress)
    ↓
Determine what to test (happy/edge/error)
    ↓
Identify dependencies to mock
    ↓
Generate test scaffolding with descriptive names
    ↓
Include AAA structure comments

Workflow

1. Analyze the Code to Test

**Identify**:

• Class name and namespace
• Methods to test (public methods)
• Dependencies (constructor parameters)
• Return types
• Drupal vs WordPress context

2. Determine Test Type

**Unit Tests** - For isolated logic:

• Services with minimal dependencies
• Utility functions
• Data transformation
• Business logic

**Integration Tests** - For component interaction:

• Controllers with database
• Form handlers
• API endpoints
• Complex workflows

**E2E Tests** - For user workflows:

• Login/authentication
• Multi-step forms
• Content creation
• Admin interfaces

3. Generate Appropriate Test Scaffold

Test Templates

Complete test templates are available for reference:

• **[Unit Test Templates](templates/unit-tests.md)** - PHPUnit (Drupal/WordPress) & Jest
• **[Integration Test Templates](templates/integration-tests.md)** - Functional tests & API testing
• **[E2E Test Templates](templates/e2e-tests.md)** - Cypress & Playwright

Use these templates as starting points, adapting for the specific code being tested.

Generation Strategy

1. Start Simple

Generate basic test structure first:

• Test class/describe block
• Setup/teardown methods
• One or two simple test cases

2. Identify Test Cases

For each public method:

• **Happy path** (valid input → expected output)
• **Error cases** (invalid input → exception)
• **Edge cases** (empty, null, boundary values)
• **State changes** (before/after verification)

3. Mock Dependencies

Identify what needs mocking:

• Database calls
• External APIs
• File system operations
• Time-dependent code

4. Add Assertions

Check:

• Return values
• State changes
• Side effects
• Error handling

Quick Response Patterns

For Simple Classes

When user shows a class with 2-3 methods:

1. Identify the test type (unit vs integr