proposal: cmd/go: add a way to suppress OK status printing in go test

[bep]

Proposal Details

Running go test ./... on a project with many packages and having all of the ok ... (cached) [no tests to run] lines repeatedly flickering over the screen is

1. probably not a good thing for eyes/people with epilepsy.
2. making identifying failing tests harder than it should be (having to scroll up looking for that FAILED statement)

Tests should ideally be fast enough that these status messages should not be needed.

I have searched for this, and the closest I have found is a go nuts thread that suggests something ala:

go test ./... |  grep -Ev "^(\?|ok)\s+"

Which works, but this should be a flag or something on the go test command.

[earthboundkid]

making identifying failing tests harder than it should be (having to scroll up looking for that FAILED statement)

I am also annoyed by this. Maybe it could repeat the names of the first N failing tests at the end, although I guess just suppressing the OK statements would work too.

[adonovan]

Running go test ./... on a project with many packages and having all of the ok ... (cached) [no tests to run] lines repeatedly flickering over the screen is

1. probably not a good thing for eyes/people with epilepsy.

I don't know how serious you are, but it doesn't seem like a problem 'go test' can solve: rapidly printing test failures is the reason it exists. If flicker is a problem, the place to tackle it is the terminal emulator or editor, the window system, or even the display hardware (like motion blurring in a TV).

2. making identifying failing tests harder than it should be (having to scroll up looking for that FAILED statement)

Tests should ideally be fast enough that these status messages should not be needed.

Is the objection to printing (cached) when nothing happened, or to printing anything at all on success? If we're going to print the test running time, then we should also print (cached), because we should aim for the behaviors of cache hits and misses to be as close to each other as possible in all ways but speed. An option to suppress all successful items seems reasonable on its face--though configuration options can lead to death by a thousand paper-cuts.