New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: poor error message when non-test Go file is in a xx_test package other than the directory name #24895

Open
stevenroose opened this Issue Apr 17, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@stevenroose

stevenroose commented Apr 17, 2018

What version of Go are you using?

$ go version
go version go1.10 linux/amd64

Does this issue reproduce with the latest release?

I guess this is the latest release.

What operating system and processor architecture are you using?

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/steven/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/steven/gocode"
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build002363276=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Using the ginkgo cli tool, I created a test suite bootstrap. The folder name is testsuite, so the tool defaulted to a package name testsuite_test.

I changed the package name in all files to cbsproxy_test, the package I'm testing, which is itself located in a different subdirectory on the same level as testsuite.

I ran both go build and go test.

What did you expect to see?

go build to succeed normally and go test to produce test results for 0 tests.

What did you see instead?

(newlines mine)

can't load package: package github.com/san-lab/cbsproxy-go/testsuite: 
found packages cbsproxy (cbsproxy_suite_test.go) and cbsproxy_test (common.go) 
in /home/steven/gocode/src/github.com/san-lab/cbsproxy-go/testsuite

Just to proof that all packages are named cbsproxy_test:

$ head -n 1 ./*.go
==> ./balance_test.go <==
package cbsproxy_test

==> ./cbsproxy_suite_test.go <==
package cbsproxy_test

==> ./common.go <==
package cbsproxy_test

What solved the issue?

Renaming common.go to common_test.go resolved the issue. The error message was however not clear. As should it be possible to have both normal Go files and _test Go files with the same package name (as with any normal package that does not end in _test).

@davecheney

This comment has been minimized.

Contributor

davecheney commented Apr 17, 2018

Can you please create a git repo somewhere with broken and non broken versions of the packages as a reproduction. Thanks

@stevenroose

This comment has been minimized.

stevenroose commented Apr 17, 2018

@davecheney https://github.com/stevenroose/testing

Non-broken is by renaming common.go to common_test.go.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Apr 17, 2018

A file in a xx_test package should always be named yy_test.go. The go tool decides which files are in a test based on the name of the file, not on the package clause.

Since you had a non test file, the go tool expected it to have a package clause that matched the directory name. But I agree that the error message could perhaps be clearer.

@ianlancetaylor ianlancetaylor changed the title from go tool incorrectly reading packages to cmd/go: poor error message when non-test Go file is in a xx_test package other than the directory name Apr 17, 2018

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Apr 17, 2018

@stevenroose

This comment has been minimized.

stevenroose commented Apr 17, 2018

Wait, non-test files don't need to have a package that matches the directory, right?

I do understand that in this case, as common.go had xx_test, that any_test.go would be expected to have xx_test_test.

@jubobs

This comment has been minimized.

jubobs commented Jun 27, 2018

I've just got bitten by this. The behaviour is counterintuitive and the error message is misleading.

@ackratos

This comment has been minimized.

ackratos commented Oct 24, 2018

I've just got bitten by this. The behaviour is counterintuitive and the error message is misleading.

me too, I might can have a look at my weekend

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment