create-tests git:20261005.8154ecdA

Immutable. This exact content never changes and is served at /api/v1/blob/d98762fec4166fcf.

---
name: create-tests
description: Create a test plan and test cases covering acceptance criteria, edge cases, and failure scenarios.
argument-hint: "[requirements or specification]"
---

# Create Tests

Produces a test plan with structured test cases derived from requirements, acceptance criteria, and a specification.
Covers happy paths, edge cases, and failure scenarios across relevant test levels.

## Prerequisites

- Apply the shared SDLC conventions in `skills/sdlc/references/shared.md`.
- If no argument is provided, locate the feature directory under `.sdlc/features/` whose frontmatter `issue` field references `$ISSUE_NUMBER`.
- `.sdlc/features/N-<slug>/requirements.md` and `.sdlc/features/N-<slug>/specification.md` (both must have passed review with findings verdict `approved`), or documents provided in context or as a file path (`$1`)
- `.sdlc/features/N-<slug>/lifecycle.md` (optional, if a lifecycle document was produced): include test cases that verify state transitions, guard conditions, invariants, and retention policies
- `.sdlc/features/N-<slug>/telemetry.md` (optional, if a telemetry plan was produced): include test cases that verify analytics events are emitted correctly
- `.sdlc/features/N-<slug>/observability.md` (optional, if an observability plan was produced): include test cases that verify metrics, logs, and traces are emitted correctly
- Information about the testing stack (if available)

## Steps

1. Read the requirements, specification, lifecycle document, telemetry plan, and observability plan (if present).
2. List all acceptance criteria that need to be verified. In `requirements.md` these are the fenced `gherkin` scenarios, each tagged with its requirement ID (`@FR-N` / `@NFR-N`); map test cases to scenarios via that tag.
3. For each acceptance criterion, write at least one test case. When the project uses a BDD framework (pytest-bdd, cucumber), a gherkin scenario can be executed directly; otherwise translate the scenario's Given/When/Then into the test case's Setup/Steps/Expected.
4. For each analytics event in the telemetry plan, write a test case verifying the event is emitted with correct properties.
5. For each metric, log entry, and trace span in the observability plan, write a test case verifying it is emitted correctly.
6. Add edge case and failure scenario tests beyond the acceptance criteria.
7. Organize test cases by test level (unit, integration, end-to-end).
8. Identify test infrastructure and fixtures needed.
9. Write the output to `.sdlc/features/N-<slug>/tests.md`.

## Test Case Format

```markdown
### TC-<N>: <Test name>

**Level:** Unit / Integration / E2E
**Covers:** FR-1 / NFR-2 / Edge case
**Setup:** <Preconditions and test data>
**Steps:**
1. <Action>
2. <Action>
**Expected:** <Observable result>
```

## Output Format

Use the template at `skills/sdlc/templates/features/tests.md` (copied to `.sdlc/templates/features/tests.md` by `/initialize-sdlc-directory`; use the project's customized copy if present). Write the result to the artifact path named in the steps above.

## Outcome

If `$OUTCOME_YAML` is set, emit `verdict: approved` there per `skills/sdlc/references/shared.md`, If the test plan could not be produced, omit the file.
In the same emission, list the artifact under `artifacts:` (`.sdlc/features/N-<slug>/tests.md`).

## Example Usage

**Scenario 1: Password reset feature**
Requirements define a 4-step reset flow.
Create unit tests for token generation and expiry, integration tests for the email dispatch call, and an E2E test for the full user journey.
Edge cases: expired token, already-used token, invalid email.

**Scenario 2: API endpoint**
Spec defines a `POST /orders` endpoint.
Write unit tests for input validation, integration tests for DB writes, E2E test for the full order placement flow, and failure tests for duplicate requests and DB errors.

## Completion Checklist

Before handing off to review, confirm:

- [ ] Telemetry events and observability signals have assertions verifying they fire correctly

Self-check the plan against the [`review-tests` checklist](../review-tests/SKILL.md) and fix what you can, so review finds less to flag.

## Next Step

A review subagent is dispatched automatically to run `/review-tests` to audit coverage, correctness, and missing scenarios before moving on.
Once approved, continue with `/create-implementation`.