A coverage-guided fuzzing solution for testing Go packages, especially those parsing complex or untrusted inputs.
go-fuzz is a coverage-guided fuzzing tool for the Go programming language. It automatically generates random inputs to test Go packages, aiming to discover crashes, hangs, memory issues, and logical bugs. It is especially useful for packages that parse complex or untrusted data, helping developers harden their code against malicious inputs.
Go developers working on packages that parse inputs (e.g., image decoders, protocol parsers, text processors) or systems exposed to untrusted data (e.g., network services, file parsers). It is also valuable for security researchers and teams prioritizing robustness.
go-fuzz provides a powerful, automated way to uncover deep, hard-to-find bugs in Go code that traditional testing often misses. Its coverage-guided approach efficiently explores code paths, and its integration with the Go toolchain and support for custom validation logic make it both practical and highly effective for improving code reliability.
Randomized testing for Go
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses code coverage feedback based on AFL to intelligently mutate inputs, efficiently exploring new execution paths and uncovering bugs, as detailed in the README's technical credits.
Allows writing Fuzz functions for application-level checks like round-trip serialization or equivalence testing, enabling deep bug detection beyond basic crashes, as shown in the PNG example.
Automatically minimizes and deduplicates test inputs with support for initial seed corpora, making fuzzing more effective over time, mentioned in the corpus collection section.
Can coordinate multiple worker processes across machines via a coordinator, enabling scaled fuzzing efforts, as described in the distributed fuzzing notes.
Has only preliminary support for Go Modules, with issues like vendor directories being ignored and requiring workarounds like setting GO111MODULE=off, as admitted in the README.
Requires writing specific Fuzz functions, managing corpus directories, and instrumenting builds, which can be non-trivial and time-consuming compared to simpler testing tools.
Cannot test code directly in package main, forcing restructuring into separate packages, which adds overhead and limits testing flexibility for some applications.
The hashed coverage bitmap can lead to hash collisions if the cover value exceeds ~5000, potentially missing new interesting inputs, a noted trade-off in the README's logging explanation.