Since a long time, I wanted to improve the output and the performance of
the subcommand `go test`, this weekend I ended working in a PoC.
My reasons are manly UX improvements, the output of running several tests
using `./...` is hard to read if you are using `-v`, since the fails of the
first packages are lost is the scroll for example. And if you use the
command without `-v` you lack of important information as the skipped tests
or just the numbers of tests executed.
Other reasons to improve the `go test` commands are performance reasons,
generating a unique `main.go` generated file, and compiling a unique
binary, saves a few secs (3 secs, on my machine, I didn't made deep tests),
running the tests from a package (eg.: golang.org/x/net) with several
nested ones. And going farther a task running plan can be calculated, to
run the tests from the packages containing changes.
At the end IMO the `go test` subcommand or any other subcommands can be
improved by the community, in this and many of the ways. if it were more
open to be extended, now days this is extensively hard due to the following
- None of the functionally on `cmd/go`  is exposed
- `cmd/go` comes with black magic to build packages including `*_test.go`
being the only way to compile a package whit those files. In the same way
handling `*_test` or `internal` packages.
- The logic between all the subcommands is extremely coupled being
impossible to extract the subcommand part of the code as a standalone
- The `Test` signature involves a pointer to a Struct, a not a interface.
The whole point of this post, is bring that the community can win a lot
from having a tool-chain more extendable and open.
BTW I am more than interested on help to improved toolchain.
Best regards and thanks.
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.