testing: colorize output on failing tests

[wymli]

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

$ go version
go version go1.16.2 windows/amd64

Proposal

Can we have color print when unit test case fail?

What did you expect to see?

Maybe we can have color print when unit test pass or fail, we can make a switch in pkg testing like t.RedErrorf(...)or cmd go test like go test ./... --color

What did you see instead?

When we have many test cases, and normally we will add -v to debug, it's hard to find the failed case.
Because we have many test flags,likego test $(go list ./... | grep -v "/neverTest") -coverprofile=cover.out -covermode=conut -gcflags=all=-l -v, the go test cmd will be placed in a unit_test.sh typically.
We won't change the script, keeping -v, which will bring many debug messages, resulting in the fact that it's hard for us to find which case failed.

By the way, do we have some better ways to only test some dirs, or exclude some dirs?

[seankhliao]

I believe this is best handled outside the go tool, eg with https://github.com/rakyll/gotest

[wymli]

I believe this is best handled outside the go tool, eg with https://github.com/rakyll/gotest

rakyll/gotest is excellent, but it is hard to persuade the tech lead to introduce non-official cmd tools into company's ci/cd pipeline.

[davecheney]

why would you colorise ci? in my experience most ci systems do not use ansi color

[wymli]

why would you colorise ci? in my experience most ci systems do not use ansi color

Before ci, i will run it locally to verify the program behavior, using the same script.
You don’t want the two environments to use different commands, right?

[wymli]

but if ci doesn’t support ansi colours, then you’re going to get a vomit of line noise in return.

for human vision:
in my campany, ci log supports ansi colors.
And it will be a kind of disaster to search the detail of why it failed from all black string in your ci log.

for auto parsing:
the ci pipeline will parse file cover.out, which is generated using -coverprofile=cover.out, without detail colorful log.

and yeah, maybe i could have two sricpts, one for ci using go test, and one for dev machine using rakyll/gotest.

[invidian]

Also, right now there is no way to distinguish the output from t.Log, t.Errorf and t.Fatalf. Would be nice to have Error and Fatal printing in red, while Log would remain as default. Alternatively, some tags on log level could be printed.

[Shaun1]

I'd like to second this request. Right now, the output from go test can be quite hard to read, especially for large test suites.

I would love to see something like a "pretty print" mode/flag for more human readable output, but as a start, I think coloring "ok" green and "FAIL" red would go a long way to making the dev experience better when running tests.

[Shaun1]

I believe this is best handled outside the go tool, eg with https://github.com/rakyll/gotest

Can you expand upon why you believe this? One of the strong points of Go I've found is that much of the standard development toolkit is ready to go "out of the box". In my experience, having to spend time deciding on third party libraries for relatively trivial things like test output is not time well spent for dev teams.

[sneko]

I agree it should be embedded to facilitate onboarding (as for autoformatting...)

Also, just for record: now using https://github.com/gotestyourself/gotestsum as it also brings "watch" feature and some other things :)

[nobody4t]

+1