API Testing.

You are a senior QA engineer specialising in API testing. Generate a comprehensive set of API test scenarios from the OpenAPI specification or description provided below.

API name and version: {{API_NAME}}
OpenAPI spec or endpoint description:
{{OPENAPI_SPEC}}

Authentication mechanism: {{AUTH_MECHANISM}}
Authorisation rules (who can access what): {{AUTHZ_RULES}}
Known business rules or constraints: {{BUSINESS_RULES}}

Generate a test scenario table with the following columns:
Scenario ID | HTTP Method | Path | Scenario description | Input conditions | Expected status code | Expected response behaviour | Category

Cover ALL of the following scenario categories for each endpoint provided:

**Positive (happy path)**
- Valid request with all required fields
- Valid request with optional fields included
- Valid request with optional fields omitted

**Negative — input validation**
- Missing required field(s)
- Invalid data type (e.g. string where integer expected)
- Value outside allowed range or enum
- Request body that is empty or malformed JSON
- Oversized payload (if applicable)

**Authentication and authorisation**
- Missing authentication token
- Expired or invalid token
- Valid token but insufficient permissions (if {{AUTHZ_RULES}} are defined)

**Schema validation**
- Response body matches documented schema for each status code
- Required response fields are present

**Pagination, filtering, and sorting** (where applicable)
- Valid pagination parameters
- Page beyond total count
- Invalid sort field or direction

**Idempotency and concurrency** (for mutating endpoints)
- Duplicate submission of the same request (idempotency check)

**Rate limiting** (if documented)
- Request count at, below, and above the rate limit threshold

Format the table in Markdown. After the table, list any scenarios you could not generate due to missing information and what additional spec detail would be needed.

Important: Do not include real credentials, API keys, customer identifiers, or production data in any example values — use synthetic placeholders only.

You are a senior QA engineer with expertise in Postman and Bruno API collections. Generate a structured collection outline for the API described below.

API name: {{API_NAME}}
API base URL pattern: {{BASE_URL_PATTERN}}
Tool preference: {{TOOL}} (Postman or Bruno)
Endpoints to include: {{ENDPOINTS}}
Authentication type: {{AUTH_TYPE}}
Environments needed: {{ENVIRONMENTS}} (e.g. local, staging, production)

Generate a collection outline covering:

1. **Folder structure** — how requests are grouped (by resource, by user journey, or by test type). Show the folder hierarchy.

2. **Environment variable strategy** — list all variables needed ({{BASE_URL}}, {{AUTH_TOKEN}}, etc.) with a note that actual token values must be stored in environment files, never hardcoded in requests or committed to source control.

3. **Authentication setup** — how to configure auth at the collection level so individual requests inherit it. For OAuth or JWT, describe the pre-request script pattern to obtain and refresh tokens.

4. **Request list** — for each endpoint, list:
   - Request name
   - Method + path
   - Key request body fields (using synthetic placeholder values — no real data)
   - Test assertions to include (status code, response schema check, key field values)

5. **Test assertion patterns** — JavaScript (Postman) or Bru lang (Bruno) snippets for:
   - Asserting status code
   - Asserting a response field value
   - Extracting a response value into a collection variable for use in subsequent requests (e.g. save created resource ID)

6. **Common pitfalls** — 3–5 things to watch out for when building this collection (e.g. token expiry, environment variable naming conflicts, hardcoded IDs between users).

Important: Use synthetic placeholder values throughout. Never include real API keys, passwords, customer identifiers, or production URLs in the generated outline.

You are a senior QA automation engineer specialising in REST Assured and Java API testing. Generate a REST Assured test class from the specification below.

Endpoint: {{HTTP_METHOD}} {{ENDPOINT_PATH}}
API base URL (staging only — never production): {{BASE_URL}}
Authentication: {{AUTH_MECHANISM}}
Request schema:
{{REQUEST_SCHEMA}}

Response schema:
{{RESPONSE_SCHEMA}}

Business rules and acceptance criteria:
{{ACCEPTANCE_CRITERIA}}

Test data (synthetic only — no real credentials, customer IDs, or PII):
{{TEST_DATA}}

Requirements for the generated class:
- Use REST Assured's given/when/then fluent DSL.
- Extract base URL and auth headers into a RequestSpecification or BaseApiTest — do NOT hardcode secrets. Use System.getenv() with a comment explaining where to set the value.
- Cover: 2xx happy path, missing required fields (400), invalid field values (400), unauthenticated request (401), and at least one schema validation test using Hamcrest matchers or JSON Schema validation.
- Annotate tests with JUnit 5 @Test. Use @Nested classes to group positive vs negative tests.
- If request or response schema details are incomplete, add TODO comments for a human to fill in.
- Assert response body field values, not just HTTP status codes.
- State all assumptions in an "Assumptions" section comment at the top of the class.

Output:
1. An assumptions comment block.
2. The complete Java test class.

You are a senior QA automation engineer specialising in Karate DSL for API testing. Generate Karate feature files for the endpoint described below.

Endpoint: {{HTTP_METHOD}} {{ENDPOINT_PATH}}
Base URL configured in karate-config.js: {{BASE_URL_VAR}} (variable name, not the actual URL — never hardcode URLs)
Authentication: {{AUTH_MECHANISM}}
Request schema:
{{REQUEST_SCHEMA}}

Response schema:
{{RESPONSE_SCHEMA}}

Business rules:
{{BUSINESS_RULES}}

Test data (synthetic only — no real credentials, user IDs, or PII):
{{TEST_DATA}}

Generate Karate feature files covering:

1. **Happy path scenario** — valid request with all required and optional fields; assert status code and key response fields using match assertions.
2. **Negative — missing required fields** — one scenario per required field; assert 400 status and the error response body.
3. **Negative — invalid field values** — invalid data types, out-of-range values; assert appropriate 4xx responses.
4. **Authentication** — missing token (assert 401); invalid token (assert 401).
5. **Schema validation** — use Karate's match response == {…} or match each to validate response shape, not just individual fields.
6. **Data-driven scenarios** — use Scenario Outline and Examples table for multiple valid and invalid input combinations.

Requirements:
- Store base URL and auth token in karate-config.js variables, not hardcoded in feature files.
- Use Karate's configure headers or a callonce auth setup, not inline tokens per scenario.
- Use match assertions to check response bodies, not assert on string-converted responses.
- Add a comment above each scenario explaining what it verifies and why.
- State all assumptions at the top of each feature file as a comment.

Output: the complete Karate feature file(s), ready to save in src/test/java/<package>/features/.

You are a senior QA engineer specialising in API security and negative testing. Generate a focused set of negative, authentication, and authorisation test scenarios for the API described below.

API name: {{API_NAME}}
Endpoints to cover: {{ENDPOINTS}}
Authentication mechanism: {{AUTH_MECHANISM}}
User roles and their permissions: {{ROLES_AND_PERMISSIONS}}
Known validation rules: {{VALIDATION_RULES}}
Tool to write scenarios for: {{TOOL}} (e.g. Postman, REST Assured, Karate — or 'table format' for tool-agnostic)

Generate test scenarios covering all of the following:

**Authentication failures**
- Request with no Authorization header
- Request with a malformed token (not a valid JWT/API key format)
- Request with an expired token (describe how to simulate this)
- Request with a token signed with the wrong secret (for JWT)

**Authorisation / role-based access control**
For each role defined in {{ROLES_AND_PERMISSIONS}}, test:
- A role attempting to access a resource it should not (assert 403)
- A role accessing a resource belonging to a different user (IDOR check — assert 403 or 404)

**Input validation**
- Missing each required field individually (assert 400 with a meaningful error body, not just status code)
- Invalid data types for each field (string where integer expected, etc.)
- Boundary values: below minimum, above maximum (where applicable)
- Empty string and null values for required fields
- Oversized string or array fields (if limits are documented)

**Response validation**
- Error responses must include a machine-readable error code (not just an HTTP status) — check this for each negative scenario
- Error messages must not reveal internal system details (stack traces, database names, file paths)

Format: produce a Markdown table with columns: Scenario ID | Method | Path | Scenario | Input | Expected status | Expected response behaviour.
After the table, list any scenarios you could not cover due to missing information.

Use synthetic placeholder values only — no real tokens, user IDs, credentials, or customer data.