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

Open
howardjohn opened this issue Jul 6, 2023 · 5 comments
Open
Milestone

Comments

@howardjohn
Copy link
Contributor

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
@rittneje
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.)

@seankhliao
Copy link
Member

or just use a different separator like -

@bcmills
Copy link
Contributor

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.

@howardjohn
Copy link
Contributor Author

howardjohn commented Jul 10, 2023

@bcmills while that is true its going to be dramatically less efficient than a single invocation. https://blog.howardjohn.info/posts/go-build-times/#concurrent-builds showcases this a bit; running two compile jobs concurrently in different processes seems to get very very little caching benefits.

https://blog.howardjohn.info/posts/go-build-times/#integration-tests 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

@Defined2014
Copy link

Defined2014 commented Jan 25, 2024

Another method is to generate the binary in its own directory to avoid conflicts (a simple example), but this will break compatibility.

Maybe we could add a new flag to do this.

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

No branches or pull requests

6 participants