Test File Organization Standards

This rule applies to files matching the patterns above.

# Test File Organization Standards

## Rule
Hurl test files MUST follow consistent naming and organization conventions. One logical test flow per file, grouped by API domain, with separate files for success and error cases.

## Directory Structure
```
tests/api/
├── auth/
│   ├── login-success.hurl
│   ├── login-invalid-credentials.hurl
│   ├── register-success.hurl
│   └── token-refresh.hurl
├── users/
│   ├── crud-flow.hurl
│   ├── list-pagination.hurl
│   ├── get-not-found.hurl
│   └── update-validation.hurl
├── products/
│   ├── crud-flow.hurl
│   ├── search-filter.hurl
│   └── create-unauthorized.hurl
└── health/
    └── health-check.hurl
```

## Naming Convention
- Use kebab-case: `login-success.hurl` not `LoginSuccess.hurl`
- Include the action: `create-user.hurl`, `list-products.hurl`
- Include the expected outcome: `login-invalid-credentials.hurl`
- CRUD flows: `crud-flow.hurl` (create → read → update → delete)

## File Size Guidelines
| File Type | Max Requests | Description |
|-----------|-------------|-------------|
| Single operation | 1-2 | One request + verification |
| CRUD flow | 4-8 | Create → Read → Update → Delete |
| Complex flow | 8-12 | Auth → multiple operations → cleanup |

## Examples

### Good — Descriptive, Focused
```
tests/api/users/crud-flow.hurl        # Full CRUD lifecycle
tests/api/users/get-not-found.hurl    # 404 error case
tests/api/auth/login-success.hurl     # Happy path login
tests/api/auth/login-expired-token.hurl  # Error case
```

### Bad — Vague, Unfocused
```
tests/test1.hurl           # Meaningless name
tests/all-tests.hurl       # Everything in one file
tests/api.hurl             # Too broad
```

## Anti-Patterns
- All tests in a single .hurl file (hard to debug, maintain, parallelize)
- Vague file names (test1.hurl, api.hurl)
- No directory structure (flat list of files)
- Mixing success and error tests in the same file without clear separation