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: Test helper code not found #32379
Comments
When you import a package, you only import its non-test code. This is true even if you're importing the package from a test file. I can't find an exact quote on this, though. The spec doesn't speak of this, because I think this is implemented in the Go tool via build tags. |
OK, but then how do I stop my test code from building when I call |
The files included in a package when built are the same files that are included in a package when you import it. So I'm not sure I see what you're trying to do. It's normal to have a test helper/utility package, but often it's an internal package so that only the owner's packages can import it. |
Normally, test code doesn't get compiled unless you call What I want is to preserve this behavior and also be able to have common test code. But the go tool seems to be one-or-the-other. If I put my common test code in a *_test.go file, it can't be imported by my other test code. If I put it in a regular *.go file, it gets compiled even when I'm not calling |
Yes, that is how it works. In your case outer appears to be a test helper package containing simple asset methods. Rename the files in that package so they do not end in |
That was just a toy project to illustrate the problem. My primary concern is with a bigger project with lots of test support code that I don't want compiling unless I'm actually running the tests. |
I think this is mostly a hypothetical question. From the outline you provided outer will be cached by go build/test. I know the go team care about compilation time. I suggest you try and iff there is a problem, raise a new bug with the concrete details. |
@kstenerud, I suspect that the error message you see is coming from the (#29258 proposes to remove this extension mechanism, because it is confusing and can add overhead to builds even when it works.) |
CC @jayconrod |
I looked into this a bit. It's working as intended. +1 to what @mvdan and @davecheney said above. It is possible to define test-only exported definitions, but they're only visible to tests in the same package. If you need test-only definitions visible to other packages, they need to be regular exported definitions in a regular package that's only imported by tests. Just to recap on the current semantics:
The last point is the source of a lot of bugs and complication. The cached copies of packages recompiled due to that rule aren't usable for other tests, which blows up the build time. I think any expansion of those semantics would be too expensive and too confusing. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go.mod:
inner/something_test.go:
inner/something.go:
package inner
test/dummy.go:
package test
test/test_helpers_test.go:
$ go test
What did you expect to see?
I expected the tests to run without error.
What did you see instead?
The text was updated successfully, but these errors were encountered: