(maybe this shouldn't be a proposal, it seems trivial enough that we should just do it?)
_Inspired by rakyll's suggestion in #16768._
I propose a small change to go test's "coverprofile" flag to output both the binary coverage format as well as HTML. The file extension passed in by the user would switch the output format (".html" for HTML, anything else for the existing behaviour).
This change is simple and highly unlikely to break existing users, unlike #16768, which suggests to add additional flags that overlap with "go tool cover" and can quickly descend into supporting more and more flags.
Before:
go test -coverprofile foo.out && go tool cover -html foo.out -o foo.html && rm foo.out
After:
go test -coverprofile foo.html
I propose a to allow -coverprofile to support multiple file names / types. For example -coverprofile p.bin p.html p.json should output binary, html, and json. That way it allows for future extension of formats out of the box and it allows the user / tool to control exactly what gets returned by the tool. What do you think?
Please don't tie behavioural changes to magic file name interpretation.
Perhaps instead:
go test -coverhtml x.html
Like -json, this flag would only exist in the go command, not in the actual test binaries.
Better, but this is still the prototypical kind of thing a small shell script (or function) can solve in a more efficient (and probably even more convenient) way.
Let's just do this for Go 1.11.
/cc @bcmills
I have started a implementation of this feature in https://github.com/zegl/go/commit/605724f2cd526bca46c47c0b298ca688cfa5eb8d. Before I open a PR I'd like to discuss one thing:
go tool cover -html profile creates a temporary file and opens it in the browser when the -o option is not set.
https://github.com/golang/go/blob/34fb5855eb73fe04ee0bcfc0d9ca8be5440a560b/src/cmd/cover/html.go#L84-L88
Should a "naked" go test -coverhtml be allowed (no value set) and use the same behaviour? Or should -coverhtml always be set to a filename?
Should a "naked"
go test -coverhtmlbe allowed (no value set) and use the same behaviour?
Probably yes.
CC @jayconrod
Most helpful comment
Perhaps instead:
Like -json, this flag would only exist in the go command, not in the actual test binaries.