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.

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.

Workflow

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

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

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.

Related Resources

Explore more resources that work well with this one.

Used in Playbooks

Complete workflows that include this resource as a step.

AI Code Review Workflow Workflow · 5 steps AI Debugging Workflow Workflow · 5 steps AI Legacy Code Modernization Workflow Workflow · 4 steps AI Code Refactoring Workflow Workflow · 4 steps

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

Explore all resources