FAQ
Hi there,

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[1].

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
reasons:

- None of the functionally on `cmd/go` [2] 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
package.
- 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.

[1] https://github.com/mcuadros/tim
[2] https://github.com/golang/go/blob/master/src/cmd/go

--
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 golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nigel Tao at Apr 14, 2016 at 2:58 am

    On Tue, Apr 12, 2016 at 12:32 AM, Maximo Cuadros wrote:
    - None of the functionally on `cmd/go` [2] is exposed
    Well, yes, it's a command, not a library, so it hasn't been written to
    be extensible.

    I'm not very familiar with how cmd/go works, but it's not obvious to
    me what some of your improvements are. For example, you mention
    "generating a unique `main.go` generated file, and compiling a unique
    binary". How is this different from what "go test" does? Similarly,
    you talk about nested tests. Do you mean the "..." in something like
    "go test net/..."? Again, what's the difference in approach between
    your PoC and cmd/go?

    It may be that some of your observations are simply bugs in cmd/go,
    and the best response could be the easier approach of patching cmd/go
    instead of the harder approach of refactoring a library out of cmd/go.
    Again, I'm not very familiar with cmd/go internals. If you provide
    more specific proposals, or more details on what you said earlier,
    perhaps somebody else with more knowledge could provide specific
    responses.

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 11, '16 at 5:22p
activeApr 14, '16 at 2:58a
posts2
users2
websitegolang.org

2 users in discussion

Nigel Tao: 1 post Maximo Cuadros: 1 post

People

Translate

site design / logo © 2021 Grokbase