gb test -v / test.v should always output test output

[davecheney]

Currently test output is suppressed unless the test fails, in which case everything is printed.

Passing -v to gb test should case the output to be printed always, even if successful

[davecheney]

#450 broke the debug logging out of gb, so -v is free to be used to enable test debug output.

[brandonbloom]

The behavior differs a bit from go test, which will emit test output while the tests run. That's a super useful behavior for iterating on tests, especially ones that can hang or take a non-trivial amount of time. Is there some other recommendation for that workflow?

[davecheney]

Please note, this issue is marked as closed.

The behaviour of go test is inconsistent, when run with only a single package, all output is sent to stdout unbuffered, when run with multiple packages, output is buffered. gb test always buffers the output even when there is one package because the gb default behaviour is to do the equivalent of go test ./...

[brandonbloom]

Would you prefer I open a new issue?

I didn't realize go test's behavior was inconsistent. That partly explains some confusion that both I and a colleague had when getting started with Go. However, I think the rest of the confusion is the buffering of output in the first place. What's the advantage of doing that when verbose logging is enabled? Seems like a strict disadvantage in that it is misleading about which test is running and make it very annoying to debug via printf.

[davecheney]

gb always tests packages in parallel, so does the go tool providing you
give it more than one package to work with. When your testing packages in
parallel, you have to buffer the output.

On Fri, Feb 26, 2016 at 2:07 PM, Brandon Bloom notifications@github.com
wrote:

Would you prefer I open a new issue?

I didn't realize go test's behavior was inconsistent. That partly explains
some confusion that both I and a colleague had when getting started with
Go. However, I think the rest of the confusion is the buffering of output
in the first place. What's the advantage of doing that when verbose logging
is enabled? Seems like a strict disadvantage in that it is misleading about
which test is running and make it very annoying to debug via printf.

—
Reply to this email directly or view it on GitHub
#438 (comment).

[brandonbloom]

Huh, I had no idea it did that either. I guess it's only documented in go build and indirectly in the testing package. It looks like builds are run in parallel, but parallelism for tests is per package, not per test case, unless you explicitly request otherwise. Thanks for the explanation.