-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added generated seeds for FuzzRangeNodes #35
Conversation
Reading and extrapolating from https://go.dev/doc/fuzz/, the Fuzz test will only be fully exercized when a single Fuzz test is run explicitly with the -fuzz parameter to go test. When running go test without this, the Fuzz test will be invoked, but only on the seed corpus. As FuzzRangeNodes did not have a seed corpus, then this test is effectively skipped in our presubmits and CI pipeline. This change adds the generated corpus from running the fuzz test as the seed corpus. This shouldn't change how well the test is covered when the -fuzz parameter is provided, but does mean that the test will be exercised as part of CI. This seems like a win, but maybe it's bonkers to be submitting generated files?
@hickford PTAL as the instigator of this fuzzing adventure. |
It doesn't appear that this generated corpus ever becomes stable; after copying the generated corpus into the seed corpus and running the fuzz command again, new "interesting" entries are always found. I've tried repeating this 3 times and there's always something new. |
Indeed Simplest solution is to add some explicit cases with F.add: for begin := 0; begin <= 10; begin++ {
for end := begin; end <= 20; end++ {
f.Add(uint64(end), uint64(end))
}
} Ultimately could add the project to https://google.github.io/oss-fuzz/ (continuous fuzzing on Google infrastructure) and https://google.github.io/clusterfuzzlite/ (fuzzes pull requests in GitHub Actions) |
I considered the [1] My understanding is that the "interestingness" of the test cases is determined via code coverage instrumentation, so using these rather than a simple for loop should allow more interesting test cases that a human might not predict or be lucky enough to capture with the simple for loop seed generation. |
Good point |
The middle ground could be more along the lines of the classic test cases pattern, with params taken from the generated files: for s, e, p := range []struct{
start int64
end int64
phaseOfMoon
}{
{ 1, 3, 6 },
...
} {
// fuzziness(s, e, p)
} I do kinda like the idea of having the fuzz seed data near the fuzz test it's for (thinking of future me wondering what on earth these weird files checked in under |
There's no need to define the struct and iterate it; you can just repeatedly add things:
But even this approach I find a bit weird; these could just be normal unit tests at this point. I proposed this approach to just lean into the automated generation and tooling that fuzzing provides, but ensure it's being used. I think the world's not ready for this yet though. For now, I think we just take the easy seeding approach @hickford suggests above:
We should also have a policy that any failures that are found through deeper fuzzing are moved to a standard unit test to prevent regressions. |
Having the explicit I also suspect this blurry line between fuzz and unit test is by design; |
#37 fuzzes beyond the seed corpus in GitHub Actions using ClusterFuzzLite. |
Reading and extrapolating from https://go.dev/doc/fuzz/, the Fuzz test will only be fully exercised when a single Fuzz test is run explicitly with the -fuzz parameter to go test. When running go test without this, the Fuzz test will be invoked, but only on the seed corpus. As FuzzRangeNodes did not have a seed corpus, then this test is effectively skipped in our presubmits and CI pipeline.
This change adds the generated corpus from running the fuzz test as the seed corpus. This shouldn't change how well the test is covered when the -fuzz parameter is provided, but does mean that the test will be exercised as part of CI. This seems like a win, but maybe it's bonkers to be submitting generated files?
The generated corpus was acquired with the following commands: