cmd/go: test files are not built if there are no Test* functions #8337
Labels
Milestone
Comments
I created a test repo that shows the effect this can have on `test ./...`: https://github.com/wadey/go8337 If you run: {{{ $ go get github.com/wadey/go8337 $ go test github.com/wadey/go8337/a/... }}} You will get the following error (even though that package exists): {{{ # github.com/wadey/go8337/a/c a/c/c_test.go:6: can't find import: "github.com/wadey/go8337/z" ok github.com/wadey/go8337/a/b 0.008s FAIL github.com/wadey/go8337/a/c [build failed] }}} This is because go1.3 thinks it built the .a files for `z` as part of testing `a/b`. But the build for `a/b` was actually skipped, thus `z` wasn't built. |
|
Issue #8555 has been merged into this issue. |
|
Issue #8219 has been merged into this issue. |
CL https://golang.org/cl/150980043 mentions this issue. |
|
This issue was closed by revision 754cd54. Status changed to Fixed. |
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 25, 2018
go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
(1) x_test.go has syntax errors
(2) x_test.go has type errors
(3) x_test.go has runtime errors (say, a func init that panics)
In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.
This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like
func TestAlwaysPasses(t *testing.T) {}
That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.
Fixes golang#8337.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, r
https://golang.org/cl/150980043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 26, 2018
go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
(1) x_test.go has syntax errors
(2) x_test.go has type errors
(3) x_test.go has runtime errors (say, a func init that panics)
In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.
This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like
func TestAlwaysPasses(t *testing.T) {}
That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.
Fixes golang#8337.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, r
https://golang.org/cl/150980043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 9, 2018
go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
(1) x_test.go has syntax errors
(2) x_test.go has type errors
(3) x_test.go has runtime errors (say, a func init that panics)
In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.
This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like
func TestAlwaysPasses(t *testing.T) {}
That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.
Fixes golang#8337.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, r
https://golang.org/cl/150980043
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 30, 2018
go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
(1) x_test.go has syntax errors
(2) x_test.go has type errors
(3) x_test.go has runtime errors (say, a func init that panics)
In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.
This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like
func TestAlwaysPasses(t *testing.T) {}
That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.
Fixes golang#8337.
LGTM=iant
R=golang-codereviews, iant
CC=adg, golang-codereviews, r
https://golang.org/cl/150980043
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What does 'go version' print? go version go1.3 darwin/amd64 What steps reproduce the problem? If possible, include a link to a program on play.golang.org. 1. In an empty package create the following a_test.go file: {{{ package a func A() { badcode } }}} 2. Run `go test .` What happened? ok a 0.007s What should have happened instead? # a ./a_test.go:4: undefined: badcode FAIL a [build failed] Please provide any additional information below. This is a regression in go1.3. go1.2 would have compiled the test file and shown the compilation error. Perhaps this isn't a bug, but it causes other issues with compilation of dependencies when using `go test ./...`. I can submit the other issues as a separate bug if this is working as intended.The text was updated successfully, but these errors were encountered: