/spdd-api-test

Generate a comprehensive, self-contained shell script (scripts/test-api.sh) with cURL commands to test all API scenarios defined in the codebase or acceptance criteria.

Key Feature: Structured Test Case Tables

The generated script includes human-reviewable test case tables:

1. At script top: A structured table showing all test scenarios, inputs, and expected outputs
2. After execution: A results table showing expected vs actual results with pass/fail status

This makes it easy for humans to:

• Review test coverage at a glance
• Verify expected values are correct
• Quickly identify which tests failed and why

Input: The argument after /spdd-api-test is a reference to generated code, acceptance criteria document, or API specification.

Input can be provided in several ways:

1. File/folder reference: Using @ to reference files containing API implementations or ACs
2. Text description: Direct text describing the API endpoints to test
3. Combined: Both file references and additional context

Examples:

# Reference to generated code
/spdd-api-test @src/main/java/com/example/controller/BillingController.java

# Reference to acceptance criteria
/spdd-api-test @spdd/prompt/GGQPA-XXX-202603131530-[Feat]-token-usage-billing.md

# Reference to multiple files
/spdd-api-test @src/controllers/ @requirements/api-spec.md

# With additional context
/spdd-api-test @src/api/ test the billing endpoints with edge cases for zero tokens

Steps

1. Validate and consolidate input context

   a. If no input provided, use the AskUserQuestion tool (open-ended, no preset options) to ask:

   "Please provide the API implementation files, acceptance criteria, or API specification to generate tests for (you can use @file references or text description)."

   IMPORTANT: Do NOT proceed without input context.

   b. If input contains @ file/folder references:

   • Read ALL referenced files completely using the Read tool
   • For folder references, read all relevant API-related files (controllers, routes, handlers)
   • Consolidate all file contents into a unified API context

   c. Extract API information:

   • Identify all API endpoints (HTTP method, path, request body schema)
   • Extract acceptance criteria and expected behaviors
   • Identify validation rules and error scenarios
   • Note any seed data or test data requirements

2. Identify seed data and test fixtures

   a. Search for existing seed data:

   • Look for seed SQL files, fixtures, or test data in common locations:
     • src/main/resources/db/migration/
     • src/test/resources/
     • fixtures/
     • seed/
     • scripts/seed*.sql
   • Read relevant seed files to understand available test data

   b. Document available test entities:

   • Customer IDs, names, and states
   • Plan IDs, pricing configurations
   • Quota configurations and limits
   • Any other domain-specific test data

   c. If no seed data found, derive test data from:

   • Entity definitions in the codebase
   • Example values in acceptance criteria
   • Common test data patterns

3. Design structured test case tables

   Before generating the script, organize test cases into logical tables by test pattern.

   Group tests by their input/output structure:

   a. Validation Error Tests (expect HTTP 400/404):

   | Test ID | Description              | Customer     | Model      | Prompt | Completion | HTTP | Expected Error           |
   |---------|--------------------------|--------------|------------|--------|------------|------|--------------------------|
   | AC1.1   | Missing modelId          | CUST-001     | (missing)  | 1000   | 500        | 400  | Model ID is required     |
   | AC1.2   | Missing customerId       | (missing)    | fast-model | 1000   | 500        | 400  | Customer ID is required  |
   | AC1.6   | Non-existent customer    | NON-EXISTENT | fast-model | 1000   | 500        | 404  | Customer not found       |