cmd/go: -test.gocoverdir cannot be used for non-curdir packages #73842
Comments
cyphar
changed the title
|
Updated since it turns out that even explicitly naming the subpackages or doing readarray -t pkgs < <(go list -f "{{ .Dir }}" ./...)
[[ "$GOCOVERDIR" =~ ^/ ]] || GOCOVERDIR="$PWD/$GOCOVERDIR"
for dir in "${pkgs[@]}"
do
pushd "$dir"
go test -cover -test.gocoverdir="$GOCOVERDIR" .
popd
done |
gabyhelp
added
the
BugReport
|
as I understand, -test.coverdir is an argument understood only by test binaries, rather than go test itself. Once go test sees a flag that it doesn't recognize, any remaining flags and arguments are passed directly to the test binary, so your package list goes to the test binary as arguments, rather than to go test as packages to test. Since this is using undocumented internal details, I don't think we're going to make any change, especially now that the new behavior has been around for a few years. |
|
Wait, is this really undocumented? There is no other way of using FWIW I found another workaround in that thread though, |
|
I guess there should be a feature request opened to support this then, given that the utility of |
Uh oh!
There was an error while loading. Please reload this page.
Go version
go version go1.24.3 linux/amd64
Output of
go envin your module/workspace:What did you do?
I'm trying to migrate an existing project that uses a bunch of hacks to get coverage from integration and unit tests to using
go build -cover/GOCOVERDIR=fooandgo test -cover -test.gocoverdir=fooinstead. However, it turns out thatgo test ./...behaviour changes with-test.gocoverdir=foo.You can verify this in any project by just observing the output difference between
go test -cover ./...andgo test -cover -test.gocoverdir=foo ./..., but here's an example:% mkdir -p gotest/{a,b,c,d,e,f,g} % cd gotest % go mod init gotest go: creating new go.mod: module gotest go: to add module requirements and sums: go mod tidy % for dir in */; do echo "package ${dir%/}" >"$dir/doc.go"; done % echo "package main" > main.go % go test -cover ./... ? gotest [no test files] ? gotest/a [no test files] ? gotest/b [no test files] ? gotest/c [no test files] ? gotest/d [no test files] ? gotest/e [no test files] ? gotest/f [no test files] ? gotest/g [no test files] % go test -cover -test.gocoverdir=foo ./... ? gotest [no test files]As far as I can tell,
-test.gocoverdirhas had this behaviour since at least Go 1.14 (though I believe-test.gocoverdirwas an implementation detail that wasn't widely used untilGOCOVERDIRandgo build -coversupport were added in Go 1.20).EDIT: Upon some further testing, it turns out that even naming subpackages doesn't work:
Even if you are only running a single test package:
What did you see happen?
Only the current directory had its tests run:
-coverpkg=./...doesn't affect the output.What did you expect to see?
You would expect
./...to recursively run the tests like regulargo testdoes:... or at least return an error if the behaviour is intentional. And named test packages should absolutely have their tests run.
Silently not running tests is quite concerning behaviour, and I only noticed this because I have a minimum coverage percentage for my project that was broken by switching to
-test.gocoverdir=.... I wouldn't have noticed otherwise that my unit tests weren't running. I wonder how many people have switched and haven't noticed that they are running fewer tests than they did before.The obvious workaround is to manually list the package names withgo list ./....EDIT:
go test -cover -test.gocoverdir=foo $(go list ./...)doesn't work. You need to run the test for each subpackage in a subshell in that directory.The text was updated successfully, but these errors were encountered: