Engineering

Validation Test Prompt

Required fields one at a time, invalid formats, business rules at their exact boundaries — validation tested the way users break it.

Open in Test Case Prompt Generator

Overview

Validation logic accumulates rules until nobody knows what's enforced — and tests that assert "invalid input fails" without saying which rule caught it. This setup generates validation tests for form logic with Jest: required fields tested missing one at a time (each with its own test), invalid formats against the patterns the code claims to enforce, invalid state transitions, and business rule violations at their exact boundaries — plus the edge-case section's six input groups, because validation is where edge cases live.

How to use this resource

One rule, one test

Required fields missing one at a time — a combined test that fails tells you nothing about which rule broke.
Test the claimed formats

The email regex, the date pattern, the ID shape — each format the code claims gets a passing and failing case.
Sit on the boundaries

Business rules tested AT their limits — the 18 in "must be 18+" gets tests at 17, 18, and 19.

Why This Works

Rule isolation turns validation failures into one-line diagnoses
Format testing catches the regex that enforces less than everyone assumed
Boundary placement finds the off-by-one in every age check and quantity limit

Best for

Forms whose validation grew rule by rule
APIs that validate at the boundary and must say why
Teams that found an unenforced "required" field in production

Not for

Security-focused input testing (injection) — toggle the Security coverage area or use the auth preset
Defining the validation rules — the tests verify what's specified, they don't invent policy

Use cases

Testing signup and checkout form validation logic
Verifying each required field fails independently
Pinning business rules at their numeric boundaries

FAQ

Why does the validation test prompt insist on one required field missing per test?

So a failure names the broken rule. The Validation coverage area specifies "Required fields missing — one at a time, each with its own test," because a combined test that fails tells you nothing about which rule caught it. Paired with output names that "complete the sentence 'it ...'," a red test becomes a one-line diagnosis rather than a hunt.

Does this prompt define my validation rules or just test the ones already in the code?

It tests what's there. TESTING OBJECTIVE says "Generate tests only — do not modify the implementation," and NON-GOALS add "Do not invent requirements — test only specified or clearly implied behavior." It checks formats against "the patterns the code claims to enforce" and business rules at their exact boundaries, listing unresolved behavior under ASSUMPTIONS and GAPS instead of inventing policy.

Which framework conventions does the generated validation test file follow?

Jest. FRAMEWORK GUIDANCE returns one runnable Jest file: mock at the module boundary with jest.mock, reset mocks in beforeEach for independence, test async with async/await and expect(...).resolves/.rejects, and group tests in describe blocks whose names complete "it ...". You still run the file and confirm the assertions in your own suite.

Customize This Resource

Opens this setup in Test Case Prompt Generator. Generate to get the full test contract — then adjust the strategy, framework, coverage, and depth.

Open in Test Case Prompt Generator

Prompt Template

Copy it as-is, or use Open in Test Case Prompt Generator to load it pre-filled and customize it with your own context.

TESTING OBJECTIVE
Test the signup form validation logic against every way users break forms.
Strategy: unit tests — isolate the unit, mock its dependencies, test the business logic.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the code under test here]

TEST STRATEGY
- Test one unit in isolation: every external dependency (database, network, clock, filesystem) is mocked or stubbed.
- Test business logic and decisions, not plumbing — getters, mappers, and pass-throughs earn tests only when they carry rules.
- One behavior per test; the test name states behavior, condition, and expected result.
- Tests must be fast and deterministic — no real I/O, no real time, no ordering dependence.

COVERAGE AREAS
Happy Path:
- The primary success path with realistic, typical inputs
- The most common variations users actually exercise
- Expected outputs asserted precisely — values and shape, not just "no exception"
Validation:
- Required fields missing — one at a time, each with its own test
- Invalid formats: emails, dates, IDs, and the patterns the code claims to enforce
- Invalid state transitions rejected with the specified behavior
- Business rule violations tested at their exact boundaries

EDGE CASES
- null/None/undefined inputs at every entry point
- Empty strings, collections, and payloads
- Minimum and maximum allowed values
- Just-inside and just-outside boundary values (off-by-one)
- Malformed and wrong-type inputs
- Unicode, emoji, and special characters in text inputs

FAILURE SCENARIOS
Each of these gets at least one test:
- A mocked dependency throws — the unit handles or propagates as specified
- Invalid arguments at every public entry point
- Boundary returns from dependencies (empty result, null, maximum size)
- State-dependent behavior called in the wrong state

TEST DATA GUIDANCE
- Use realistic, production-shaped data — names, amounts, and dates that could exist.
- Build complex objects with builders or factories, not hand-assembled literals repeated per test.
- Name boundary data for its intent (maxLengthName, expiredToken), not its value.
- Never share mutable fixtures between tests.

FRAMEWORK GUIDANCE
Framework: Jest.
- Mock at the module boundary with jest.mock; reset mocks in beforeEach so tests stay independent.
- Test async code with async/await and expect(...).resolves / .rejects — no done-callback patterns.
- Use snapshots only for stable, reviewed output — a snapshot nobody reads is not an assertion.
- Use describe blocks per behavior group; test names complete the sentence "it ...".

OUTPUT FORMAT
- Return one complete, runnable test file in Jest.
- Group tests by coverage area, with a comment header per group.
- Each test: arrange-act-assert structure, one behavior per test.
- Cover every selected coverage area systematically — each coverage item above gets at least one test.
- Parametrize repetitive cases instead of copy-pasting tests.
- Name tests so a failure message alone identifies the broken behavior.

ASSUMPTIONS
- After the tests, list every assumption you made about unspecified behavior under an ASSUMPTIONS heading.
- Where the code's intent is ambiguous, test the most likely intent and flag the ambiguity.
- List GAPS: behaviors you could not test with the information given.

NON-GOALS
- Do not rewrite or "improve" the implementation code — test it as it is.
- Do not refactor the architecture to make it more testable; flag testability problems instead.
- Do not invent requirements — test only specified or clearly implied behavior.
- Do not weaken assertions to make tests pass.

More resources from Test Case Prompt Generator

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

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.

Engineering

Resource

Agent Safety & Refusal Evaluation Prompt

Test the two failure directions — does the agent refuse what it must, and does it stay helpful on the benign requests it shouldn't over-refuse?

AI Agents

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Test Case Prompt Generator

Build test generation prompts — unit, integration, or E2E — with framework modes and edge-case coverage rules.

Coding Workflows

Projects that use this resource

Project

Build an AI Support Agent with AI

The full path to a support agent you can put in front of customers — write its instructions, ground it in your docs, route and handle tickets, then evaluate and cost-control it before it goes live.

10 stages AI Systems

Project

Build a RAG System with AI

The full path to a retrieval system that returns grounded answers — understand the corpus, chunk and ground it, extract and classify the metadata, then evaluate that retrieval actually works.

5 stages AI Systems

Project

Build an AI Workflow Automation System with AI

The full path to automation that survives the real world — wire the integrations and triggers, design the control API, move the data through validated stages, evaluate the AI steps, then deploy.

5 stages AI Systems

Project

Build a Customer Support System with AI

The full path to a support operation, not just a bot — stand up the knowledge base, route the tickets, add the AI agent, integrate your stack, close the feedback loop, evaluate, and deploy.

9 stages Business Systems

Tip: Save time by exploring related resources and tools that integrate with this resource.