Yes. Plain go test runs each seed corpus entry against the fuzz target like a unit test, with no fuzzing. Fuzzing itself starts only when you pass -fuzz. Any failing input saved under testdata/fuzz is replayed on every normal test run, so it works as a regression test.
What the Go documentation says
The Go fuzzing documentation states that fuzz tests are run much like a unit test by default: each seed corpus entry is tested against the fuzz target, and failures are reported before exiting. Actual fuzzing begins only with go test -fuzz=FuzzTestName.
The seed corpus is made of two things: entries added in code with f.Add, and the files in the testdata/fuzz/FuzzTestName directory of the package. The docs say those files are run by default with go test, whether fuzzing or not.
Where failures go
When the engine finds a failing input, it minimizes it and writes it into the seed corpus, with a message such as "Failing input written to testdata/fuzz/FuzzFoo/" followed by a hash. The docs say that input will now be run by default with go test, serving as a regression test once the bug has been fixed.
Entries the engine keeps while exploring, called the generated corpus, live in the Go build cache under $GOCACHE/fuzz and are only used while fuzzing. They are not part of your repository and are not replayed by plain go test.
| Location | Committed? | Runs in plain go test? |
|---|---|---|
f.Add calls in the test | Yes, it is code | Yes |
testdata/fuzz/FuzzName/ files | Yes, you commit them | Yes |
| Build cache fuzz directory | No | No, only while fuzzing |
Practical steps
- Run the fuzz target for a short time with the fuzz flag.
- If it fails, read the file it wrote under
testdata/fuzz. - Fix the bug.
- Run plain
go testand confirm the saved input now passes. - Commit the new file with the fix.
The docs list the same next steps: fix the bug, rerun go test, and submit the patch with the new testdata file.
What a corpus file looks like
Each file starts with a version line, go test fuzz v1, followed by one line per argument of the fuzz target. The values must match the target's argument types and order. Because the files are plain text, they review well in a pull request. A reviewer can see exactly what input triggered the bug.
Why QA should care
This means your normal CI job, which probably already runs go test ./..., replays every past fuzzing failure for free. You do not need a separate pipeline step for regressions. You only need a separate, time boxed job if you want new fuzzing in CI.
Treat the testdata directory as security evidence. Do not delete files from it to make a build pass. If a file is wrong, understand why before removing it.
One caution: an input that came from a real incident may contain personal data. Replace it with a synthetic equivalent that still triggers the bug before committing.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a code level finding is traced to a location, and compare that with a fuzz input pointing at a failing branch.
Safeguard covers dependency and SBOM scanning, with a free scan. Fuzz targets for your own code stay in your repository.
Quick check
Does go test start fuzzing on its own?
No. Without the fuzz flag it only runs the seed corpus entries once each.
Should I commit the testdata fuzz files?
Yes. They are the regression record for past failures. Clean out sensitive content first.
Sources
Last reviewed: 19 October 2026.
