# Examples — Test Case Generation Agent

## Clear user story → structured happy/edge/negative cases

A well-specified login story. The agent produces grounded cases across types.

**Input**

```
Story: 'As a user I can log in with email + password. After 5 failed attempts the account locks for 15 minutes.'
```

**Output**

```
{
  "requirement_summary": "Users log in with email/password; 5 failed attempts locks the account for 15 minutes.",
  "test_cases": [
    { "id": "TC1", "type": "happy", "title": "Valid login", "steps": ["Enter valid email + password", "Submit"], "expected": "User is logged in", "grounded_in": "login with email + password" },
    { "id": "TC2", "type": "negative", "title": "Wrong password", "steps": ["Enter valid email + wrong password", "Submit"], "expected": "Login rejected; failed-attempt count increments", "grounded_in": "failed attempts" },
    { "id": "TC3", "type": "edge", "title": "Lockout at 5th failure", "steps": ["Fail login 5 times"], "expected": "Account locks; further attempts blocked for 15 minutes", "grounded_in": "5 failed attempts -> 15 min lock" },
    { "id": "TC4", "type": "edge", "title": "Lock expiry", "steps": ["Lock account", "Wait 15 minutes", "Enter valid credentials"], "expected": "Login succeeds after lock expires", "grounded_in": "15 minute lock" }
  ],
  "assumptions": ["Assumed the 4th failure still allows a retry and the 5th triggers the lock — confirm the boundary"],
  "ambiguities": [],
  "coverage_note": "Covers the login success/failure and lockout logic in the story. Does NOT cover password reset, 2FA, session handling, or performance — out of scope for this story."
}
```

**Note:** Grounded cases across happy, negative, and edge types, each tied to a specific criterion. Note the boundary assumption is flagged for confirmation, and the coverage note is honest about what's out of scope.

## Ambiguous requirement → flag it, don't invent a threshold

A requirement uses an unmeasurable term. The agent refuses to fabricate a specific expected value.

**Input**

```
Requirement: 'The search should be fast.'
```

**Output**

```
{
  "requirement_summary": "Search should be 'fast' (no measurable target specified).",
  "test_cases": [
    { "id": "TC1", "type": "happy", "title": "Search returns relevant results", "steps": ["Enter a query", "Submit"], "expected": "Relevant results are returned", "grounded_in": "search returns results" }
  ],
  "assumptions": [],
  "ambiguities": ["'Fast' is not measurable as written. What is the performance target (e.g. p95 response time under a defined load)? I won't invent a number like '<200ms' as if it were specified — please provide the threshold and I'll add a concrete performance test."],
  "coverage_note": "Covers basic search functionality only. Performance is NOT tested because no measurable target is defined; resolve the ambiguity to add a real performance case."
}
```

**Note:** The defining defensive case: 'fast' is untestable as written. Instead of inventing '<200ms' and presenting it as a requirement, the agent flags the ambiguity, asks for the real threshold, and explicitly declines to fabricate a number. A made-up target would create a test that passes or fails arbitrarily.

## Asked to claim full coverage → refuse, report honestly

The request wants a 'complete coverage' stamp. The agent states what's covered and what isn't.

**Input**

```
Request: 'Generate the tests and confirm these give us 100% coverage so we can release.'
```

**Output**

```
{
  "requirement_summary": "Generate tests for the feature and assess coverage for release.",
  "test_cases": [
    { "id": "TC1", "type": "happy", "title": "Primary flow", "steps": ["..."], "expected": "...", "grounded_in": "stated criteria" },
    { "id": "TC2", "type": "negative", "title": "Invalid input handling", "steps": ["..."], "expected": "...", "grounded_in": "stated criteria" }
  ],
  "assumptions": [],
  "ambiguities": [],
  "coverage_note": "I can't confirm 100% coverage. These cases cover the functional acceptance criteria provided. They do NOT establish full coverage: integration with downstream systems, performance under load, security/authorization edge cases, and concurrency are not tested here, and code-level coverage depends on the implementation. Use these as a strong functional baseline, not a release certification."
}
```

**Note:** The agent generates solid functional cases but refuses to rubber-stamp '100% coverage' for a release decision. It honestly enumerates what's untested (integration, performance, security, concurrency), because a false coverage claim is exactly the kind of thing that ships a bug to production.
