Engineering

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.

Open in Test Case Prompt Generator

Overview

The most dangerous change is one to untested legacy code: nothing fails because nothing was watching. This setup builds the safety net first — characterization tests that pin current behavior exactly as it is, even where it looks wrong (assert the actual output, flag the suspicious cases), previously-fixed bugs covered by name, and output formats asserted exactly where downstream consumers parse them. The failure scenarios are regression's own: fixed bugs returning, drift in untouched paths, formats changing shape under their consumers.

How to use this resource

Pin before you plan

Characterization tests come before the refactor design — you can't protect behavior you haven't recorded.
Assert the weird outputs too

If it returns a trailing space today, the test asserts the trailing space — and flags it. Consumers may depend on the weirdness.
Name the historical bugs

Each previously-fixed bug gets a test carrying its ID — the regression suite doubles as the bug museum.

Why This Works

Characterization honesty (assert what IS) makes untested code changeable
Bug-by-name coverage converts incident history into permanent protection
Format pinning protects the integrations nobody remembers exist

Best for

Legacy modules about to be changed for the first time in years
Code whose only spec is its current behavior
Teams that found out about a regression from a customer

Not for

Judging whether the legacy code is good — that's the Code Review Prompt Generator's mentoring review
Actually refactoring it — pin first, then the Refactor Prompt Builder

Use cases

Building a safety net before refactoring a legacy module
Pinning output formats that downstream systems parse
Covering historical bugs so they can't quietly return

FAQ

Why does this prompt tell the AI to assert buggy output instead of the correct output?

Because characterization tests pin what the code does today, not what it should do. The TEST STRATEGY says to "assert actual current output, even where it looks wrong, and flag the suspicious cases" — a trailing space today gets asserted and flagged, since a downstream consumer may depend on it. The test-case-prompt-generator outputs these tests; you run and review them.

How does this prompt keep a fixed bug from silently coming back after a refactor?

The COVERAGE AREAS require previously-fixed bugs "covered by name, one test each," and the FAILURE SCENARIOS explicitly include "a previously-fixed bug reappears after a refactor." You supply the historical behavior; the generated tests name each bug so a failure message identifies the regression. The tests protect behavior, they don't guarantee correctness.

Will the generated tests be locked to pytest or JUnit?

It doesn't. FRAMEWORK GUIDANCE is set to Generic, so it uses "the project's existing test framework and follows its established conventions" rather than imposing one. For a specific framework's idioms, regenerate in the test-case-prompt-generator with that framework selected. Either way it returns one runnable file grouped by coverage area, not code you've confirmed runs.

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
Build a safety net of characterization tests before changing this legacy module.
Strategy: regression tests — pin the current behavior so future changes cannot silently alter it.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the behavior under protection here]

TEST STRATEGY
- Protect existing behavior: the tests document what the system does TODAY, before anything changes.
- Cover previously-fixed bugs by name — each known failure gets a test that would catch its return.
- For untested legacy code, write characterization tests: assert actual current output, even where it looks wrong, and flag the suspicious cases.
- Pin output formats exactly where downstream consumers parse them.

COVERAGE AREAS
Regression:
- Current behavior pinned before any change lands
- Previously-fixed bugs covered by name, one test each
- Output formats asserted exactly where consumers parse them

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 previously-fixed bug reappears after a refactor
- Behavior drifts in code paths the change was not supposed to touch
- An output format changes shape and breaks its consumers
- An edge case that worked before stops working

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 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.

5 steps 30–45 minutes

Workflow

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.

5 steps 20–40 minutes

Workflow

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.

4 steps 45–90 minutes

Workflow

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.

4 steps 30–60 minutes

Workflow

AI Performance Optimization Workflow

Speed up code that works but drags — find the actual hot path instead of guessing, understand why it's slow, optimize it, and prove with tests that you changed the speed and nothing else.

4 steps 30–60 minutes

Guides for this resource

Guide

How to Review Code for Performance With AI Without Guessing the Bottleneck

Ask AI to "review this for performance" and you get a tidy list of smells with no idea which one production actually spends time on. Here is how to review code for performance with AI so each finding is tied to a workload, ranked by evidence, and marked with the measurement that would confirm it.

Software Development with AI

Guide

How to Reproduce a Bug With AI

You click the thing twenty times, it works every time, and you close the ticket "cannot reproduce" — while it keeps happening to users. Here is how to reproduce a bug with AI: turn a vague report into conditions that make the failure appear and disappear on demand, without inventing the ones you were not given.

Software Development with AI

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