Skip to content
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

proposal: cmd/go: support naming compiled tests with full qualified name #61199

howardjohn opened this issue Jul 6, 2023 · 4 comments


Copy link

Since #15513, we can now do go test -c -o dir/ ./.... This works great and has a lot of use cases mentioned in the issue.

The issue, though, is this requires every package to have a unique name. This is not the case for most code bases, including Go itself (you can check with go list ./... | xargs -n1 basename | sort | uniq -d I believe).

It would be great to allow an alternate naming for the compiled tests. For example, instead of naming a file a/b/c/some_test.go as c.test, it could be named a_b_c.test or similar.

This would ensure the new mode works for all codebases.

This could be a new flag, or it could be the default when using -c with multiple files. However, the latter is probably a breaking change unless its included in 1.21 which may be too late.

@seankhliao seankhliao added the GoCommand cmd/go label Jul 6, 2023
@seankhliao seankhliao changed the title cmd/go: support naming compiled tests with full qualified name proposal: cmd/go: support naming compiled tests with full qualified name Jul 6, 2023
@gopherbot gopherbot added this to the Proposal milestone Jul 6, 2023
Copy link

rittneje commented Jul 7, 2023

This can still cause a collision if I have a package named a/b and a package named a_b (unusual but not impossible).

Another option is to preserve the directory structure, so we'd end up with for example a/b/c.test. (I'd love if that were a thing for go build since you can also get collisions there.)

Copy link

or just use a different separator like -

Copy link

bcmills commented Jul 10, 2023

There is a tradeoff between ergonomics and API complexity: you always have the fallback of running go test -c on the packages individually, although getting the concurrency right could be a little tricky.

Copy link

howardjohn commented Jul 10, 2023

@bcmills while that is true its going to be dramatically less efficient than a single invocation. showcases this a bit; running two compile jobs concurrently in different processes seems to get very very little caching benefits. shows another concrete example of how we would use this, specifically to take advantage of the superior build times when compiling multiple things in a single go invocation

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

No branches or pull requests

5 participants