Closed cameracker closed 3 months ago
The only thing I would push back on is running active fuzzing (generating new input values) during CI. We should definitely run active fuzzing and commit any edge cases it finds alongside the fixes, but no one likes it when their CI build fails for something unrelated to their change.
Fixed in #148
Several years ago, @acln0 contributed a fuzz test to the package It was incorporated prior to github actions, and was not integrated into travisCI (what we were using at the time), so it hasn't made it into our CI. Additionally, the way it's invoked involves installing
dvyukov/go-fuzz
usinggo get
- it's not included ingo.mod
. And, go provides fuzzing functionality directly as of Go 1.18.We should touch this up. Fuzzing is a valuable testing practice, and even if we don't find much because our parameterized functions are so minimal, it'd still be useful to cover our bases.
I suggest fuzz testing should look like
go-fuzz
Interested in with others think!