What this prompt does
This prompt makes the AI a senior QA engineer that converts a feature spec into a comprehensive test suite. You provide the [acceptance_criteria], the [language], the [test_framework], the [class_under_test], and the [dependencies] to mock, and it generates tests across five categories: happy path, edge cases, error scenarios, data integrity, and the fixtures and factories to support them. The output is a complete, ready-to-run test file rather than scattered snippets.
The structure works because it pushes past the happy path that most developers stop at. Each acceptance criterion gets a happy-path test with a descriptive test_action_when_condition_should_result name and an Arrange-Act-Assert layout. The edge-case category forces null and empty inputs, boundary values, Unicode, and collection extremes. The error category asks what happens when each dependency fails, and [additional_test_concern] lets you pin a specific worry. Test data is built with your [factory_approach], and the rules ban magic numbers and demand real assertions instead of "no exception thrown."
When to use it
- You have acceptance criteria and want a real suite, not just happy-path coverage
- You keep skipping edge cases under deadline and want them generated for you
- You need every external
[dependencies]mocked so tests never hit real APIs - You want descriptive test names that double as documentation
- You need data-integrity checks like idempotency and cascade effects
- You want fixtures and factories scaffolded with your project's
[factory_approach]
Example output
You get a single ready-to-run test file in [test_framework], organized into the five categories with clear AAA sections and comments explaining why each edge case matters. Tests use framework-native assertions, mock every dependency you listed, and rely on [factory_approach] for setup and teardown, with parameterized data providers where they reduce duplication.
Pro tips
- Write
[acceptance_criteria]as concrete, testable statements; vague specs produce vague tests - Name
[class_under_test]with its full path so the generated test targets the right unit - List every external
[dependencies]so nothing accidentally calls a real API or database - Set
[factory_approach]to your project's real tool (Laravel factories) so setup matches your conventions - Use
[additional_test_concern]for the integrity check you care about, like tokens being hashed not stored plain - Run the suite; descriptive names and real assertions are the goal, but AI tests can still assert the wrong thing
