AI Prompts for Testing

You are a senior QA engineer writing unit tests for {{function_name}} in {{language}}.

Here is the function under test:
```
{{function_code}}
```

Testing framework: {{test_framework}}
Mocking library: {{mock_library}}

Write comprehensive unit tests covering:

1. **Happy path** — expected inputs produce correct outputs
2. **Boundary values** — empty strings, zero, max int, single-element arrays, exact thresholds
3. **Null/undefined handling** — what happens with missing or null arguments
4. **Error states** — invalid inputs that should throw or return error values
5. **Type edge cases** — wrong types, NaN, Infinity, special characters

For each test:
- Use a descriptive name: `it('should [expected behavior] when [condition]')`
- Arrange, Act, Assert pattern
- One assertion per test (prefer focused tests over multi-assert tests)
- Include a brief comment explaining WHY this case matters

Mock these dependencies: {{dependencies}}
Do NOT test implementation details — test behavior and outputs only.

Create an integration test plan for the interaction between {{component_a}} and {{component_b}} in {{system_name}}.

Architecture context:
{{architecture_description}}

Data flow: {{component_a}} sends {{data_format}} to {{component_b}} via {{communication_method}}.

For each test scenario, provide:

| # | Scenario | Preconditions | Test Steps | Expected Result | Priority |
|---|----------|--------------|------------|-----------------|----------|

Cover these interaction categories:
1. **Normal flow** — data passes correctly end-to-end
2. **Contract validation** — schema mismatches, missing required fields, extra fields
3. **Failure handling** — {{component_b}} is down, returns errors, times out
4. **Retry/recovery** — connection drops mid-transaction, duplicate messages
5. **Performance boundaries** — large payloads, high throughput, concurrent requests
6. **State management** — out-of-order messages, stale data, race conditions

Authentication between components: {{auth_method}}
Environment: {{environment}}

Prioritize by: risk of user-facing impact. Mark each test as Automated or Manual with justification.

You are a senior test engineer specialized in finding edge cases. Analyze the following feature specification and identify every edge case that could cause unexpected behavior.

Feature: {{feature_name}}
Description: {{feature_description}}

Technical implementation:
{{implementation_details}}

User inputs: {{input_fields}}

For each edge case found, provide:

### Edge Case #[n]: [descriptive name]
- **Category:** Input validation | Concurrency | State | Timing | Resource limits | Security | Data integrity
- **Scenario:** Exactly what the user/system does
- **Why it's risky:** What could go wrong
- **Expected behavior:** What SHOULD happen
- **Test approach:** How to reproduce and verify
- **Priority:** Critical / High / Medium / Low

Think about:
- What happens at exactly 0, 1, and MAX values?
- What if two users do this simultaneously?
- What if the operation is interrupted halfway?
- What if the input contains Unicode, emoji, RTL text, or SQL injection?
- What if the system clock is wrong?
- What if disk/memory is full?
- What if a dependency returns slowly or not at all?

Generate at least {{min_count}} edge cases, ordered by severity.

Generate realistic test data for {{feature_name}} in {{application_type}}.

Data schema:
{{schema_definition}}

Generate {{num_records}} records across these categories:

1. **Valid baseline data** ({{baseline_count}} records) — realistic, typical values that represent normal usage
2. **Boundary values** ({{boundary_count}} records) — min/max lengths, zero values, maximum allowed values
3. **Internationalization** ({{i18n_count}} records) — names with accents, CJK characters, RTL text, emoji
4. **Adversarial inputs** ({{adversarial_count}} records) — SQL injection attempts, XSS payloads, excessively long strings, null bytes, special characters
5. **State-specific data** ({{state_count}} records) — records in various lifecycle states: {{lifecycle_states}}

Requirements:
- All data must be internally consistent (e.g., zip codes match cities, dates are logical)
- Include relational references where applicable (foreign keys must point to valid records)
- Format as {{output_format}} (JSON | CSV | SQL INSERT statements)
- Add a comment column explaining why each record is useful for testing

Do NOT use obviously fake data like "John Doe" or "123 Main St" — use realistic but fictional values.

Write end-to-end test scenarios for {{user_journey}} in {{application_name}}.

User persona: {{persona}} ({{persona_description}})
Testing framework: {{e2e_framework}}
Base URL: {{base_url}}

For each scenario, provide:

### Scenario: [descriptive title]
**Given** [initial state and preconditions]
**When** [user actions, step by step]
**Then** [expected outcomes and assertions]

```{{language}}
// Automated test code
{{framework_specific_template}}
```

Scenarios to cover:

1. **Happy path** — complete the journey successfully from start to finish
2. **First-time user** — no prior data, empty states, onboarding flows
3. **Returning user** — existing data, saved preferences, session restoration
4. **Error recovery** — network failure mid-flow, invalid input, expired session
5. **Accessibility** — keyboard-only navigation, screen reader compatibility
6. **Mobile viewport** — responsive behavior, touch interactions

Page objects / selectors to use: {{selectors}}

Between each step, assert:
- The correct page/URL is loaded
- Key UI elements are visible and in the expected state
- No console errors are thrown
- Network requests return expected status codes

Create a regression test checklist for {{change_description}} in {{application_name}}.

What changed:
{{change_details}}

Files modified:
{{files_changed}}

Dependencies affected:
{{affected_dependencies}}

## Regression Test Checklist

### Direct Impact (test the change itself)
For each modified behavior, list:
- [ ] Test case description
- Expected result
- Test data needed

### Upstream Impact (things that call/use what changed)
Identify every component, API consumer, or workflow that depends on the changed code:
{{known_consumers}}

For each, list:
- [ ] What to verify still works
- How to test it
- Risk level (High/Medium/Low)

### Downstream Impact (things the change calls/uses)
Verify the change still correctly interacts with:
- [ ] Database queries (schema compatibility, query performance)
- [ ] External APIs (request format, error handling)
- [ ] Cache layers (invalidation, stale data)
- [ ] Background jobs (scheduling, payload format)

### Cross-Cutting Concerns
- [ ] Authentication and authorization still work
- [ ] Error handling and logging are correct
- [ ] Performance is not degraded (load time, query count)
- [ ] Backward compatibility (old clients, old data)
- [ ] Feature flags (behavior with flag on AND off)

### Smoke Tests (quick sanity checks)
List the 5 most critical user flows that must work regardless of any change:
{{critical_flows}}

Priority order: Test high-risk items first. Mark anything that can be automated vs. must be manual.