Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing: colorize output on failing tests #46921

Open
wymli opened this issue Jun 25, 2021 · 11 comments
Open

testing: colorize output on failing tests #46921

wymli opened this issue Jun 25, 2021 · 11 comments
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@wymli
Copy link

wymli commented Jun 25, 2021

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
Copy link
Member

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

@seankhliao seankhliao changed the title testing: can we have color print when unit test case fail? testing: colorize output on failing tests Jun 25, 2021
@wymli
Copy link
Author

wymli commented Jun 25, 2021

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
Copy link
Contributor

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

@wymli
Copy link
Author

wymli commented Jun 25, 2021

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
Copy link
Author

wymli commented Jun 25, 2021

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.

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 28, 2021
@dmitshur dmitshur added this to the Backlog milestone Jun 28, 2021
@invidian
Copy link

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
Copy link

Shaun1 commented Apr 16, 2022

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
Copy link

Shaun1 commented Apr 16, 2022

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
Copy link

sneko commented Jun 21, 2022

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

This comment was marked as spam.

@stevem995

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

9 participants