cmd/go: add an option for go test to test all packages in the current module

[Zerotask]

What version of Go are you using (go version)?

$ go version
go version go1.16.5 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Patrick\AppData\Local\go-build
set GOENV=C:\Users\Patrick\AppData\Roaming\go\env  
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Patrick\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Patrick\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.5
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\Patrick\dev\internal\go-testing\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\Patrick\AppData\Local\Temp\go-build1425292384=/tmp/go-build -gno-record-gcc-switches

What did you do?

I want to test all packages inside my go module.
After searching on the internet, I found on Stackoverflow, that you can use go test ./....
Even though this is documented in go help test, it's a bit hidden and it looks a bit strange.

Therefore I suggest adding a flag -all, e. g. go test -all as an (better) alternative to go test ./....

What did you expect to see?

What did you see instead?

[mvdan]

Even though this is documented in go help test, it's a bit hidden and it looks a bit strange.

Do you have any suggestions on how to make this easier to find or use?

I think we want to try improving the docs before we add more ways of accomplishing the same. Having more ways means more code and more documentation, as well as more edge cases; what should go test -all . do? What about go test -all ./...? Should the flag work in other commands?

[Zerotask]

I thought about go test -all and not go test -all ..
Just a simple command to run all tests from a module. The current solution seems a bit odd.

I like Go, but in some ways it could be easier. For example in Rust, you simply run cargo test to run all tests.

I suggested it as an alternative to avoid breaking changes.

[bcmills]

I agree that ./... is a bit of an awkward pattern, but the right concept here really is a package pattern — not a flag. (Compare #40364.)

[mvdan]

For what it's worth you do have go test all, but note that that really means everything, including all packages from your dependencies. I think it would be really weird for go test -all and go test all to do very different things.

I guess we could add go test module, though that doesn't seem particularly easier to type than go test ./....

[bcmills]

I've been mulling go test mod for a shorthand, on the theory that (a) no package should be named mod, and (b) the existing shorthand patterns like std and cmd are mostly three-letter abbreviations.

The main thing that makes ./... awkward for me is that it is relative to the current subdirectory rather than the module root.

[Zerotask]

For what it's worth you do have go test all, but note that that really means everything, including all packages from your dependencies.

Thank you for pointing that out. I didn't know that.
With that in mind, -all would be confusing, that's right.

I like the suggested go test mod or as a flag go test -mod, so this wouldn't conflict with packages named mod.

[mvdan]

Here's a reason to add a mod package pattern; gopls currently struggles to use package patterns for "the entire module": golang/tools@bfc1674

They were doing ${scope}/..., but that breaks for e.g. std/....

[seankhliao]

It seems a flag is not the way to go. a pattern for "the current module" should probably be a separate proposal