search

dvyukov / go-fuzz

Randomized testing for Go
Apache License 2.0
4.79k stars 279 forks source link

Packages missing from the coverage #142

Open Kubuxu opened 8 years ago

Kubuxu commented 8 years ago

I started writing fuzzy tests for go-ipfs but I've hit quite a big wall.

The instrumentation during build process is not performed if any package if dependency tree of given package has import "C". This causes about 80% of our code to not be instrumented by go-fuzz, which means that it doesn't really try to cover our code.

Whole problem seems to be down to net package and runtime/cgo packages which do import "C".

Kubuxu commented 8 years ago

OK, running with CGO_ENABLED=0 seems to resolve it. Is that the official way of doing it? If yes then it would be good to recommend it by default as net dependency is quite common an it screws the coverage completely.

dvyukov commented 8 years ago

CGO_ENABLED=0 is the best solution for now. Ultimately go-fuzz is integrated into Go compiler and build system, which would eliminate all these constant breakages related to cgo, vendoring, internal packages, new package naming restrictions, etc.

dgryski commented 8 years ago

@dvyukov Is there any bug open to track the steps required for this to be integrated upstream?

dvyukov commented 8 years ago

@dgryski No, there is none. Feel free to file a one. Ideally Fuzz functions can be defined in test packages along with unit tests and benchmarks and then easily executed either in continuous coverage-guided mode, or in unit testing mode (corpus is executed once and/or a fixed number of additional random inputs). Maybe it should be integrated with testing/quick package, or maybe not.