Would be nice to add a new fuzz.go. I took a quick stab at this, and feel kind of restricted to the single Fuzz() method the go-fuzz only allows. I'll keep playing with it.
I did find https://github.com/dvyukov/go-fuzz/issues/230 that led me to fzgo, which seems to speed up a multiple-package implementation of go-fuzz (creating multiple fuzz.go, within different directories). However, we'd be limited to only public Exported funcs. That still may be ok, given the isolation and coverage we'd get from multiple tests. That directory structure could look like:
podcast/fuzz.sh # script to kick of all go-fuzz tests at once, using fzgo perhaps
podcast/fuzz/podcast/fuzz.go # Fuzz() would test all funcs in podcast.go
podcast/fuzz/item/fuzz.go # Fuzz() would test all funcs in item.go
Or perhaps a structure breaking out each individual func:
podcast/fuzz.sh # script to kick of all go-fuzz tests at once, using fzgo perhaps
podcast/fuzz/AddItem/fuzz.go
podcast/fuzz/AddDuration/fuzz.go
podcast/fuzz/AddImage/fuzz.go
... and so on
I'll continue to experiment with the single fuzz.go approach in the root for now. It's getting quite messy though.
eduncan911
commented
4 years ago
Would be nice to add a new
fuzz.go. I took a quick stab at this, and feel kind of restricted to the singleFuzz()method thego-fuzzonly allows. I'll keep playing with it.I did find https://github.com/dvyukov/go-fuzz/issues/230 that led me to
fzgo, which seems to speed up a multiple-package implementation ofgo-fuzz(creating multiplefuzz.go, within different directories). However, we'd be limited to only public Exported funcs. That still may be ok, given the isolation and coverage we'd get from multiple tests. That directory structure could look like:Or perhaps a structure breaking out each individual func:
I'll continue to experiment with the single
fuzz.goapproach in the root for now. It's getting quite messy though.