Prompt Engineering

Edge Case Test Prompt — Hunt the Boundaries

Q: Which compound edge cases does this contract force, beyond testing one bad input at a time?

The FAILURE SCENARIOS block names the collisions single-input thinking misses: two edge conditions arriving at the same time, empty collections where the code assumes at least one element, and maximum-size inputs hitting limits the happy path never reaches. Each gets at least one test, so the generated prompt targets boundary pile-ups, not just a lone null.

Q: Why does this prompt tell the AI not to weaken assertions or change my code?

The NON-GOALS pin the generated tests to the implementation as-is: do not rewrite or improve the code, do not refactor for testability, and never weaken assertions to make tests pass. Testability problems get flagged instead of patched. The prompt only asks for one runnable test file grouped by coverage area; running those tests and acting on the flags stays with you.

Null, empty, min, max, off-by-one, malformed, unicode — the systematic boundary hunt that finds bugs where they actually live.

Open in Test Case Prompt Generator

Overview

Edge cases are where the bugs live, and "also test some edge cases" finds none of them. This setup makes boundary hunting the strategy itself: partition the input space and test every partition edge — null/None/undefined at every entry, empty strings and collections, minimum and maximum values, just-inside and just-outside boundaries, malformed and wrong-type inputs, unicode and emoji in every text field — with failure scenarios for the compound edges: two boundary conditions arriving at once, maximum-size inputs meeting limits the happy path never sees.

How to use this resource

Partition before you test

The strategy demands input-space partitioning — edges are found systematically, not brainstormed.
Test both sides of every boundary

Just-inside passes, just-outside fails — one without the other proves nothing.
Flag ambiguous boundaries

Where the code doesn't say whether 100 is inside, the contract tests both interpretations and says so.

Why This Works

Partitioning converts "some edge cases" into a finite, completable list
Both-sides boundary testing catches the off-by-ones single-value tests miss
Compound-edge scenarios cover the collisions that single-input thinking never reaches

Best for

Parsers, validators, and anything that touches user input
Code reviewed as correct that still fails on Tuesdays
Hardening AI-generated code, which skips edges by temperament

Not for

Journey-level edge cases (back button, refresh) — those live in the E2E strategy
Explaining why an edge case fails — that's the Debugging Prompt Generator

Use cases

Boundary-testing input-handling code before it meets real input
Finding the off-by-one in every range check
Testing unicode and emoji through every text path

FAQ

How does this prompt handle a boundary the code doesn't clearly define, like whether 100 counts as inside the max?

The TEST STRATEGY tells the model to test both plausible interpretations and flag the ambiguity for any boundary the code leaves fuzzy, and the ASSUMPTIONS section makes it list every guess about unspecified behavior plus a GAPS list. So a fuzzy '<= 100 or < 100' yields tests for both plus a written flag, not a silent choice, wherever you run the prompt.

Which compound edge cases does this contract force, beyond testing one bad input at a time?

The FAILURE SCENARIOS block names the collisions single-input thinking misses: two edge conditions arriving at the same time, empty collections where the code assumes at least one element, and maximum-size inputs hitting limits the happy path never reaches. Each gets at least one test, so the generated prompt targets boundary pile-ups, not just a lone null.

Why does this prompt tell the AI not to weaken assertions or change my code?

The NON-GOALS pin the generated tests to the implementation as-is: do not rewrite or improve the code, do not refactor for testability, and never weaken assertions to make tests pass. Testability problems get flagged instead of patched. The prompt only asks for one runnable test file grouped by coverage area; running those tests and acting on the flags stays with you.

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
Hunt the boundaries of the input-handling code — every edge that could break it.
Strategy: edge case tests — hunt the boundaries of the input space systematically.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the code under test here]

TEST STRATEGY
- Partition the input space and test every partition boundary — the bugs live at the edges, not the middle.
- For every input: null/None, empty, minimum, maximum, just-inside and just-outside the boundary.
- Malformed and wrong-type inputs are first-class test cases, not afterthoughts.
- When a boundary is unclear from the code, test both plausible interpretations and flag the ambiguity.

COVERAGE AREAS
Error Handling:
- Every declared error path actually triggers in a test
- Errors carry the right type, message, and code
- Failures leave state clean — no partial writes survive
- Errors propagate or are swallowed exactly as specified

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:
- Off-by-one at every boundary comparison
- Empty collections where the code assumes at least one element
- Maximum-size inputs hitting limits the happy path never sees
- Unicode, emoji, and special characters in every text input
- Two edge conditions arriving at the same time

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: Generic.
- Use the project's existing test framework and follow its established conventions.

OUTPUT FORMAT
- Return one complete, runnable test file.
- 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

Workflows that use this resource

Workflow

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.

5 steps 30–60 minutes

Guides for this resource

Guide

Generate Tests for AI-Written Code

Ask AI for tests and you get a green suite that only checks the happy path and agrees with the code's bugs. Here's how to generate behavior-focused tests: give the model the intended behavior as the source of truth, cover boundaries and errors, and review them yourself.

Software Development with AI

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