blob: c0f18ea3c073196dbc0cbae76597d7fff9d3966c [file] [log] [blame]
# This test demonstrates the fuzz corpus behavior for packages outside of the main module.
# (See https://golang.org/issue/48495.)
[short] skip
# Set -modcacherw so that the test behaves the same regardless of whether the
# module cache is writable. (For example, on some platforms it can always be
# written if the user is running as root.) At one point, a failing fuzz test
# in a writable module cache would corrupt module checksums in the cache.
env GOFLAGS=-modcacherw
# When the upstream module has no test corpus, running 'go test' should succeed,
# but 'go test -fuzz=.' should error out before running the test.
# (It should NOT corrupt the module cache by writing out new fuzz inputs,
# even if the cache is writable.)
go get -t example.com/fuzzfail@v0.1.0
go test example.com/fuzzfail
! go test -fuzz=. example.com/fuzzfail
! stdout .
stderr '^cannot use -fuzz flag on package outside the main module$'
go mod verify
# If the module does include a test corpus, 'go test' (without '-fuzz') should
# load that corpus and run the fuzz tests against it, but 'go test -fuzz=.'
# should continue to be rejected.
go get -t example.com/fuzzfail@v0.2.0
! go test example.com/fuzzfail
stdout '^\s*fuzzfail_test\.go:7: oops:'
! go test -fuzz=. example.com/fuzzfail
! stdout .
stderr '^cannot use -fuzz flag on package outside the main module$'
go mod verify
# Packages in 'std' cannot be fuzzed when the corresponding GOROOT module is not
# the main module — either the failures would not be recorded or the behavior of
# the 'std' tests would change globally.
! go test -fuzz . encoding/json
stderr '^cannot use -fuzz flag on package outside the main module$'
! go test -fuzz . cmd/buildid
stderr '^cannot use -fuzz flag on package outside the main module$'
-- go.mod --
module example.com/m
go 1.18