test-create

Audience: Developers needing test coverage for new or changed code.

Goal: Generate comprehensive tests using the project's framework (RSpec, Minitest, Jest, Playwright).

Instructions

When invoked, you must follow these steps:

1. Identify Test Context

   • Read the provided context about what changes have been made or what functionality needs testing
   • Determine the test type requested (Rails integration, model/service/API, unit, or Playwright component)
   • Use Grep and Glob to find existing test patterns and conventions in the codebase

2. Identify Testing Framework

   • Determine which testing framework is being used in the project
   • Look for evidence of the framework:
     • RSpec: Check for spec/ directory, _spec.rb files, rails_helper.rb, .rspec config
     • Minitest: Check for test/ directory, _test.rb files, test_helper.rb
     • Jest/Vitest: Check for *.test.js, *.spec.js, jest.config.js, vitest.config.js
     • Playwright: Check for *.spec.ts in tests/ or e2e/ directory
   • Once identified, prepare to use the appropriate skill:
     • RSpec → Use rspec-coder skill
     • Minitest → Use minitest-coder skill
     • JavaScript/TypeScript → Write tests directly (no skill yet)

3. Analyze Code Structure

   • Use Read to examine the implementation files that need testing
   • Identify all public methods, API endpoints, or component behaviors that require test coverage
   • Check for existing test files to understand the project's testing conventions

4. Research Testing Patterns

   • Search for similar existing tests in the project using Grep
   • Note any custom test helpers or fixtures being used
   • Identify patterns specific to this codebase (custom matchers, shared examples, etc.)

5. Write Test Plan

   • Create a comprehensive test plan document outlining:
     • Scope: What functionality will be tested (class/module, specific methods/endpoints)
     • Test Cases: Organized by category with detailed descriptions
       • Happy Path Scenarios: Expected successful flows
         • Test case 1 description
         • Test case 2 description
       • Sad Path Scenarios: Error handling, validations, failures
         • Test case 1 description
         • Test case 2 description
       • Edge Cases: Boundary conditions, null/empty values, unusual inputs
         • Test case 1 description
       • Authorization/Authentication (if applicable)
         • Test case 1 description
     • Test Data Requirements: Fixtures or data needed for each test case
     • Mocking Strategy: What external services/dependencies to mock and why
     • Expected Outcomes: What each test should verify (assertions, state changes)
   • Test Case Matrix (use for complex scenarios with multiple parameters):

     Objective	Inputs	Expected Output	Test Type
     Validate user creation	valid email, password	User created, returns 201	Happy Path
     Reject duplicate email	existing email	Error message, returns 422	Sad Path
     Handle empty password	valid email, ""	Validation error	Edge Case

   • When to use each format:
     • Checklist format: Simple features, clear scenarios, sequential logic
     • Tabular format: Multi-parameter functions, decision tables, boundary value analysis, API endpoints with varied inputs
   • Present the test plan to confirm coverage before implementation
   • Use TodoWrite to track test cases to be implemented as you write them

6. Invoke Appropriate Testing Skill (For Ruby/Rails tests)

   • If framework is RSpec, use the Skill tool to invoke rspec-coder
   • If framework is Minitest, use the Skill tool to invoke minitest-coder
   • Pass context about:
     • The test plan created in step 5
     • What code needs testing
     • Location of implementation files
     • Type of tests needed (model, service, controller, etc.)
     • Any custom patterns discovered in research phase
   • The skill will guide writing tests following framework-specific best practices

7. Write Test Implementation (Following the test plan)

   • Implement tests according to the test plan from step 5
   • Use TodoWrite to mark test cases as completed as you write them
   • Follow the testing skill's guidance for Ruby/Rails tests
   • For Rails Integration Tests: Test full request/response cycles, database transactions, and user workflows
   • For Model/Service/API Tests: Test business logic, validations, scopes, callbacks, and service object behaviors
   • For Unit Tests: Test individual methods in isolation with appropriate mocking/stubbing
   • For Playwright Component Tests: Test UI interactions, component states, and visual behaviors
   • Ensure all test cases from the plan are implemented

8. Ensure Test Quality

   • Include meaningful test descriptions that clearly explain what is being tested
   • Use appropriate assertions and matchers
   • Add necessary test data setup (fixtures or inline data)
   • Verify tests follow DRY principles with shared examples or helper methods where appropriate
   • Follow framework-specific conventions (from rspec-coder or minitest-coder skill)
   • Cross-check all test cases from the test plan are covered

9. Run Tests to Verify

   • Use Bash tool to execute the test file
   • For RSpec: bundle exec rspec path/to/spec_file.rb
   • For Minitest: bundle exec rake test path/to/test_file.rb or ruby -Itest path/to/test_file.rb
   • Verify all tests pass (green)
   • If tests fail, debug and fix before proceeding
   • Check test output for warnings or deprecations

10. Validate Test Coverage - Acceptance Criteria

A test is considered "DONE" when ALL of the following criteria are met:

Coverage Completeness:

• ✅ All test cases from the test plan are implemented
• ✅ All public methods have at least one test
• ✅ Happy path (success scenario) is tested
• ✅ Sad path (failure/error scenarios) are tested
• ✅ Edge cases and boundary conditions are covered
• ✅ Authorization/authentication checks (if applicable)

Test Quality:

• ✅ Tests pass successfully (green) - VERIFIED BY RUNNING
• ✅ Tests are isolated (don't depend on each other)
• ✅ Tests follow AAA pattern (Arrange-Act-Assert)
• ✅ Test names clearly describe what is being tested
• ✅ No pending/skipped tests without explanation

Framework Compliance (RSpec/Minitest specific):

• ✅ No require 'rails_helper' or require 'test_helper' (auto-imported)
• ✅ Using fixtures instead of factories (where appropriate)
• ✅ Proper use of framework-specific matchers
• ✅ Appropriate mocking/stubbing of external services
• ✅ Following project's existing test patterns

Execution Verification:

• ✅ Tests can be run in isolation (VERIFIED BY RUNNING)
• ✅ Tests run quickly (no unnecessary database operations)
• ✅ No test flakiness (consistent results)
• ✅ Test output is clear and informative

CRITICAL: Do not mark tests as complete if they fail, are skipped, or don't meet the above criteria. Always run tests before reporting completion.

Best Practices:

• Follow the AAA pattern (Arrange, Act, Assert) for test structure
• Use descriptive test names that document expected behavior
• Prefer explicit assertions over implicit ones
• Test behavior, not implementation details
• Keep tests isolated and independent from each other
• Use appropriate test doubles (mocks, stubs, spies) sparingly and purposefully
• For Rails tests, use transactional fixtures and database cleaner appropriately
• For Playwright tests, ensure proper waiting strategies and avoid flaky selectors
• Include comments for complex test logic or non-obvious assertions
• Group related tests logically using describe/context blocks
• Use shared contexts and examples to reduce duplication
• Test data should be minimal but sufficient to demonstrate the behavior

Report / Response

Provide your final response with:

1. Test Plan: Present the comprehensive test plan created in step 5, including:

   • Scope of testing
   • All test cases organized by category (happy path, sad path, edge cases, auth)
   • Test data requirements
   • Mocking strategy
   • Expected outcomes
   • Use markdown formatting with checkboxes for tracking

2. Testing Framework Identified: State which framework was detected (RSpec, Minitest, Jest, etc.)

3. Skill Used (if applicable): Indicate which skill was invoked (rspec-coder or minitest-coder)

4. Test Coverage Summary: Brief overview of what functionality has been tested

5. Test File Location: Absolute path to the created or modified test file(s)

6. Test Structure: High-level outline of the test organization (describe/context blocks, test groupings)

7. Key Test Cases Implemented: Confirm which test cases from the plan were implemented:

   • ✅ Happy path scenarios
   • ✅ Sad path/error scenarios
   • ✅ Edge cases
   • ✅ Authentication/authorization (if applicable)

8. Code Snippet: Show the most critical or complex test examples from the generated tests

9. Acceptance Criteria Verification: Confirm ALL criteria are met:

   • ✅ All coverage completeness criteria met (all test plan cases implemented)
   • ✅ All test quality criteria met
   • ✅ All framework compliance criteria met
   • ✅ All execution verification criteria met
   • Test Status: All tests passing ✅ / Some tests failing ❌

10. Execution Instructions: How to run the specific tests that were created

• Command to run all tests in the file
• Command to run specific test (by line number or description)
• Any setup required before running tests

IMPORTANT: If any "Acceptance Criteria" criteria are NOT met, clearly state which criteria are missing and what needs to be done to complete them. Do not report tests as "done" if they don't meet all criteria.

All file paths must be absolute. Focus on creating tests that serve as both verification and documentation of the system's expected behavior.