Shrinking is the step where a property based testing tool takes a large failing random input and reduces it to a smaller one that still fails. QA teams care because a ten character failing input is a defect report a developer can act on, while a ten kilobyte one is noise.
The problem shrinking solves
Property based tools generate many inputs from rules you describe. When one breaks your property, the first failing input is usually messy: long strings, odd characters, deeply nested values. Reporting that as is would waste the developer's time.
Shrinking searches for a simpler input that triggers the same failure. The output is typically the smallest example the tool could find, which points straight at the faulty condition.
How Hypothesis handles it
In the Hypothesis documentation, shrinking is one of the phases of a test run, listed as shrinking failing test cases. Failures are also saved automatically in an example database, which the docs describe as best thought of as a cache that you never need to invalidate. By default it lives under .hypothesis/examples in the working directory.
Two details matter for QA:
- The docs say not to rely on the database for correctness. To make sure Hypothesis always tries a particular input, add it with the
@exampledecorator. - Explicit examples added with
@exampledo not shrink. They are run as given, before random generation, which is what you want for a pinned regression.
A security flavored example
Imagine a function that normalizes file paths before checking they stay inside an upload folder. The property: after normalization, the result never escapes the folder.
The tool might first fail on a long string full of slashes and dots. After shrinking, the failing input could be a short sequence of dot segments. That short input does three jobs:
- It goes into the defect report as the reproduction.
- It becomes an
@exampleso the fix stays fixed. - It tells the developer which branch is wrong.
Workflow for a QA engineer
- Write a property in plain words first: "the resolved path always stays inside the base directory."
- Run the test and wait for a failure.
- Copy the shrunk input from the output, not the first raw failure.
- Confirm it fails on the current build and passes on the fixed build.
- Add it as an explicit example in the test file.
- Link the test from the ticket.
Limits to know
Shrinking finds a smaller failing input, not necessarily the smallest possible one, and different runs can end at different examples. Do not treat the shrunk value as the only trigger. Ask the developer whether neighbouring inputs also fail.
The database is a local cache, so a failure found on a colleague's machine or in CI will not appear on yours unless you share the directory or add an explicit example. Pinning the example is the reliable route.
Shrinking also depends on how the input strategy is described. Overly loose rules produce inputs a real user could never send, and a failure there may not matter. Tighten the rules to match what the application accepts, then judge severity on real reachability.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a finding only matters once you know the input can reach the code, the same question you should ask of a shrunk failure.
Safeguard's reachability analysis and free scan apply that question to dependency findings. It does not generate property tests for your own code.
Quick check
Does shrinking change what the bug is?
No. It looks for a simpler input that triggers the same failure, so the defect is the same but easier to read.
Do pinned examples shrink?
No. Hypothesis runs explicit examples as given and does not shrink them.
Sources
Last reviewed: 19 October 2026.
