API Test Prompt — the Contract Is the Subject
Status codes, response shapes, 401 vs 403, idempotency — API tests that test the contract, not the implementation.
View Resource →Coding Workflows
Test Case Prompt Generator
"Write tests for this code" gets happy-path tests with weak assertions. Pick the test strategy, the framework, and the coverage areas — and get a test generation contract: failure scenarios, edge case groups, framework discipline, and non-goals that keep the AI from rewriting your code. Runs entirely in your browser.
What is being tested, and why now? E.g. "Generate tests for the orders REST endpoint before it goes public."
Coverage Focus * (select all that apply)
Each area contributes real testing instructions to the contract — not just a heading.
Paste the code under test and the prompt carries it; leave empty and the prompt ends with a paste-here placeholder.
Coverage Preview (live — what your contract will demand)
Test Case Prompt
Authentication Test Prompt
Login, token refresh, and everything that must fail: expired tokens, wrong permissions, malicious credentials — auth tested as behavior.
View Resource →E2E Test Prompt — User Journeys, Not Functions
Cart to confirmation as a user would do it — with the failure scenarios real users actually trigger: refreshes, back buttons, double clicks.
View Resource →Edge Case Test Prompt — Hunt the Boundaries
Null, empty, min, max, off-by-one, malformed, unicode — the systematic boundary hunt that finds bugs where they actually live.
View Resource →Integration Test Prompt — the Boundary Is the Subject
Real database, real services, real transactions — integration tests that verify round-trips and rollback, not mocked theater.
View Resource →Playwright Test Prompt
getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.
View Resource →Regression Test Prompt — Pin It Before You Change It
Characterization tests for legacy code: assert what it does TODAY — bugs and all — so tomorrow's change can't lie about its impact.
View Resource →Selenium Test Prompt
Explicit waits, stale-element handling, drivers that actually quit — Selenium regression tests that hold the legacy fort.
View Resource →Unit Test Prompt — Isolation Done Right
Mock the dependencies, test the business logic, one behavior per test — the unit testing contract that bans plumbing tests.
View Resource →Validation Test Prompt
Required fields one at a time, invalid formats, business rules at their exact boundaries — validation tested the way users break it.
View Resource →AI Code Review Workflow
A complete AI-assisted review pass — not one prompt — that ends with ranked findings, tests guarding behavior, and a refactor plan when one is warranted.
View Playbook →AI Debugging Workflow
The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
View Playbook →AI Legacy Code Modernization Workflow
Update old, risky code you didn't write — safely — by understanding and pinning its behavior in tests before you change a single line.
View Playbook →AI Code Refactoring Workflow
Restructure code you own without breaking it — change only what's worth changing, and prove with tests and a diff that behavior held.
View Playbook →AI Test Generation Workflow
Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.
View Playbook →How it works
State the testing objective, then pick the test strategy — Unit, Integration, End-to-End, Regression, Edge Case, or API. Each strategy is a different testing philosophy with its own principles and failure scenarios: unit tests isolate and mock, integration tests make the boundary the subject, regression tests pin today's behavior by name. Choose the framework as a mode — xUnit theories, Jest mock discipline, Playwright's no-sleep locator rules, PyTest fixtures — and toggle the coverage areas that apply: happy path, edge cases, error handling, validation, security, performance, regression. Each area contributes real testing instructions, and the live Coverage Preview shows exactly what your contract will demand. Set the depth (Production Ready means CI discipline and a regression net, not just more tests), optionally paste the code, and click Generate Test Prompt. The output is a test generation contract — including non-goals that stop the AI from rewriting your implementation. Nothing leaves your browser.
Use cases
- Turning "write tests for this" into tests with edge cases and real assertions
- Getting framework-correct tests — Playwright that doesn't sleep, Jest that resets mocks
- Building characterization tests before touching legacy code
- Testing AI-generated code before trusting it
Pro tips
- Pick the strategy before the framework: "how should this be tested" (philosophy) comes before "what runs it" (mode). An API tested as unit tests misses the contract; a unit tested end-to-end wastes a browser.
- The non-goals section earns its place the first time the AI "improves" your implementation instead of testing it — keep it even when you trim the prompt.
- Edge Cases as a coverage area gets its own section in the prompt with six input groups (null, empty, min/max, off-by-one, malformed, unicode). If you only toggle one extra area, toggle that one.
- Use Production Ready depth for suites that run in CI: it bans the flaky patterns (sleeps, shared state, ordering) that turn green suites red on Fridays.
FAQ
How is this different from the Code Review Prompt Generator?
Different questions. Code Review asks "what is wrong with this code?" — it judges and reports findings. Test Case asks "how should this code be tested?" — it creates validation instructions. Review identifies the gaps; this tool builds the net. They meet in the middle: a review finding of "tests missing for the error path" is exactly what this tool's error-handling coverage area generates.
Why is Selenium a framework mode instead of its own tool?
Because a framework is a serializer of testing intent, not a testing philosophy. The strategy (E2E, regression) decides WHAT to test; Selenium vs Playwright vs Cypress only changes HOW the instructions are phrased — waits, locators, lifecycle. One tool with framework modes beats four tools that are 90% identical — the same reason the JSON Output Prompt Builder absorbed XML and YAML.
Does the strategy really change the output?
Each strategy swaps the philosophy block and the failure scenarios. Unit tests get isolation rules and mocked-dependency failures; integration tests get transaction rollback and partial-failure scenarios; E2E gets session expiry and double-submission; API tests get the 401-vs-403 distinction and idempotency. Same skeleton, different testing worldview.
What does the generated prompt stop the AI from doing?
The NON-GOALS section is explicit: do not rewrite or "improve" the implementation, do not refactor for testability (flag it instead), do not invent requirements, and do not weaken assertions to make tests pass. The ASSUMPTIONS section forces the model to separate what it knows from what it guessed — and to list the GAPS it couldn't test.
Should I test failing code with this, or debug it first?
Debug first — that's the Debugging Prompt Generator's job: "why is this failing?". This tool asks "how should behavior be validated?" and assumes the code's intended behavior is known. The one exception is regression strategy on legacy code: characterization tests deliberately pin current behavior, bugs and all, before you change anything.
Can it generate the tests directly?
It generates the test generation PROMPT — the contract you paste into ChatGPT, Claude, or your coding assistant along with the code. The value is repeatability: the same contract produces the same coverage discipline on every module, instead of whatever the model feels like testing today.