Roadmap

This is not a complete list of ideas, but the intent is to give a notional idea of the direction of the project, as well as to give a launch point for dialog.

This is open source, so no guarantees, and that is especially true for the "aspirational" items.

And of course, this will hopefully be further shaped by feedback and usage.

WIP Items

• General cleanup and rounding of sharp edges.
• Multiple initializers.
  • Currently the constructor or other initialization happens at start outside the sight of fz.Chain.
  • Perhaps instead, []fuzzer.Start{}.
  • fz.Chain picks one.
• fuzzer.ChainValidate.
  • Currently automatic validation (e.g., roundtrip test) is only at the end, and also happens at outside the sight of fz.Chain
  • Perhaps instead, optional arg for fz.Chain like fuzzer.ChainValidate(func(args ...interface{}) error)
  • Engine can run just at end, or in-between for invariant checking
• Option to stop an executing Chain on non-nil error
  • Currently, fz.Chain keeps going even if an error is returned by a function under test. (It sees the error, but does not stop).
  • A common pattern in hand-written fuzz targets is to stop on error. Most likely make this default behavior, with an option to not stop.

Planned

• fuzzer.Compare.
  • Compare two different implementations, with the engine flagging any differences in results.
• Some additional knobs around things like string or []byte length, possibly setting private elems of structs, possibly finer grain control around parallelism, whether or not to skip args with nil, ...
  • The goal is to not have too many knobs overall.
• fzrun
  • When you have many fuzzing targets, it is handy to be able to do 'fzrun ./...' or similar and have it loop over all. (fzgo used to support this).
• Improvements to fuzzing efficiency, including improvements to corpus encoding.
• Versioned corpus encoding.
• Casting a broader net than the current choices between a constructor focus or a package wide focus.
• Revamp CLI.

Aspirational

• Some flavor of fz.Add to programmatically add to corpus.
• fzcollect.
  • dynamically gather call sequences and arguments from a 'go test' invocation to seed or update a corpus.
• VCS aware fuzzer.Compare.
  • Perhaps separate utility such as fzcmp to juggle modules and git for you and setup a fuzzer.Compare to compare two different versions of the same code, including same major version (e.g., v1.2.3 vs. v1.2.4 or commit 8f924b9ef).
  • 100% solution might be challenging, but 80% solution might be more feasible.
• Chain a full package, including type-based wiring between methods and regular functions.
• Chain multiple packages.
• Walk back N packages to construct complex objects (vs. currently, we only walk back within one package to construct a complex object).
• Inject an additional constructor if a method takes an object of the same type (vs. currently, we just do one constructor on demand).
• Additional primitives' to target concurrency testing.
• Declarative option for engine to balance pairs of functions under test.
  • e.g., Lock/Unlock perfectly balanced by end of parallel section of execution.
  • e.g., blocking Enqueue/Dequeue allowed to get at most N out of balance.
• Some stronger or more direct flavor of a shadow model (or perhaps fuzzer.Validate and the general ability to write Go code inside or outside of the closures is sufficient?).
• Possibly externalize plan as JSON or similar.