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

cmd/cover: should support -coverprofile unifying tests from multiple packages #6909

Closed
wadey opened this Issue Dec 6, 2013 · 57 comments

Comments

Projects
None yet
@wadey
Contributor

wadey commented Dec 6, 2013

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. run `go test -coverprofile=coverage.out ./...`

What is the expected output?

coverage.out contains coverage all of the specified packages

What do you see instead?

`cannot use test profile flag with multiple packages`

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

OS X 10.9

Which version are you using?  (run 'go version')

go version go1.2 darwin/amd64

Please provide any additional information below.

If I manually construct a coverage.out file from multiple packages, it seems to work
fine:

1. go test -coverprofile a.part ./a
2. go test -coverprofile b.part ./b
3. echo "mode: set" >coverage.out
4. grep -h -v "mode: set" *.part >>coverage.out
5. go tool cover -html=coverage.out

Why can't `go test -coverprofile` do this automatically?
@minux

This comment has been minimized.

Show comment
Hide comment
@minux

minux Dec 6, 2013

Member

Comment 1:

Labels changed: added release-go1.3maybe, repo-tools.

Status changed to Accepted.

Member

minux commented Dec 6, 2013

Comment 1:

Labels changed: added release-go1.3maybe, repo-tools.

Status changed to Accepted.

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc May 9, 2014

Contributor

Comment 3:

Labels changed: added release-none, removed release-go1.3maybe.

Contributor

rsc commented May 9, 2014

Comment 3:

Labels changed: added release-none, removed release-go1.3maybe.

@hgfischer

This comment has been minimized.

Show comment
Hide comment
@hgfischer

hgfischer Jul 9, 2014

Contributor

Comment 4:

With the 1.3 release, any idea when this will be fixed?
Contributor

hgfischer commented Jul 9, 2014

Comment 4:

With the 1.3 release, any idea when this will be fixed?
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Aug 27, 2014

Comment 5 by phuna24:

I'm also facing same problem today with 1.3.1. Is there plan for fixing this soon?

Comment 5 by phuna24:

I'm also facing same problem today with 1.3.1. Is there plan for fixing this soon?
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Aug 27, 2014

Comment 6 by hwang.dev:

It is not an urgent issue. The workaround is simple, please check the shell script:
https://gist.github.com/hailiang/0f22736320abe6be71ce

Comment 6 by hwang.dev:

It is not an urgent issue. The workaround is simple, please check the shell script:
https://gist.github.com/hailiang/0f22736320abe6be71ce
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Aug 27, 2014

Comment 7 by phuna24:

Hi,
Thanks for the link. Very helpful.

Comment 7 by phuna24:

Hi,
Thanks for the link. Very helpful.
@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Oct 16, 2014

Comment 8:

CL https://golang.org/cl/159910044 mentions this issue.

Comment 8:

CL https://golang.org/cl/159910044 mentions this issue.

@wadey wadey added accepted labels Oct 16, 2014

@dlsniper

This comment has been minimized.

Show comment
Hide comment
@dlsniper

dlsniper Feb 8, 2015

Contributor

Can this be included in 1.5. I don't see any technical reason for it to not be. Thank you.

Contributor

dlsniper commented Feb 8, 2015

Can this be included in 1.5. I don't see any technical reason for it to not be. Thank you.

@mikioh mikioh changed the title from go.tools/cmd/cover: should support -coverprofile for multiple packages to cmd/cover: should support -coverprofile for multiple packages Feb 8, 2015

@minux

This comment has been minimized.

Show comment
Hide comment
@minux

minux Feb 8, 2015

Member
Member

minux commented Feb 8, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title from cmd/cover: should support -coverprofile for multiple packages to x/tools/cmd/cover: should support -coverprofile for multiple packages Apr 14, 2015

@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015

@rsc rsc removed the repo-tools label Apr 14, 2015

@andrewchambers

This comment has been minimized.

Show comment
Hide comment
@andrewchambers

andrewchambers May 13, 2015

I am interested in getting total test coverage across a DAG of packages. All the solutions online do naive merges of cover profiles via concatenation (including comment 6 here), but this does not take into account lines covered across package boundaries. +1 for anyone who can work on this.

Edited My original phrasing was bad.

I am interested in getting total test coverage across a DAG of packages. All the solutions online do naive merges of cover profiles via concatenation (including comment 6 here), but this does not take into account lines covered across package boundaries. +1 for anyone who can work on this.

Edited My original phrasing was bad.

@adg

This comment has been minimized.

Show comment
Hide comment
@adg

adg May 13, 2015

Contributor

I wouldn't say there's "no interest" but rather nobody with time to work on it.

Contributor

adg commented May 13, 2015

I wouldn't say there's "no interest" but rather nobody with time to work on it.

@andrewchambers

This comment has been minimized.

Show comment
Hide comment
@andrewchambers

andrewchambers May 13, 2015

With regard to the solution I can see two approaches:

  • Instrumenting every package in go list ./... for each run and then merging cover profiles.
  • Generating a single instrumented test binary with all tests combined. This probably means go test -c ./... produces one combined test binary.

With regard to the solution I can see two approaches:

  • Instrumenting every package in go list ./... for each run and then merging cover profiles.
  • Generating a single instrumented test binary with all tests combined. This probably means go test -c ./... produces one combined test binary.
@josharian

This comment has been minimized.

Show comment
Hide comment
@josharian

josharian May 13, 2015

Contributor

I personally want go test -c to support producing a single binary. In particular, I want go test -c std to work, so that I can easily benchmark compiler changes. Right now I have to play games to generate and manage a slew of test binaries.

However, this would require a bit of thought. Right now, all tests and benchmarks are implicitly namespaced by the package. Take for example go test -c encoding/.... Several packages have a TestEncode function. If you did ./encoding.test -test.run=Encode, should it run all of them? How do you specify just one of them? There's a similar question about output. Run e.g. go test -v -run=^TestEncode$ encoding/... and observe that the go tool is responsible for providing the output that differentiates the different packages. Same thing for benchmarks.

This is not to say it can't/shouldn't be done, just that there are some careful decisions to be made.

Contributor

josharian commented May 13, 2015

I personally want go test -c to support producing a single binary. In particular, I want go test -c std to work, so that I can easily benchmark compiler changes. Right now I have to play games to generate and manage a slew of test binaries.

However, this would require a bit of thought. Right now, all tests and benchmarks are implicitly namespaced by the package. Take for example go test -c encoding/.... Several packages have a TestEncode function. If you did ./encoding.test -test.run=Encode, should it run all of them? How do you specify just one of them? There's a similar question about output. Run e.g. go test -v -run=^TestEncode$ encoding/... and observe that the go tool is responsible for providing the output that differentiates the different packages. Same thing for benchmarks.

This is not to say it can't/shouldn't be done, just that there are some careful decisions to be made.

@tv42

This comment has been minimized.

Show comment
Hide comment
@tv42

tv42 May 13, 2015

@josharian Tests also can define their own command-line flag parsing. I don't see how you could make that work right.

tv42 commented May 13, 2015

@josharian Tests also can define their own command-line flag parsing. I don't see how you could make that work right.

@josharian

This comment has been minimized.

Show comment
Hide comment
@josharian

josharian May 13, 2015

Contributor

I would think that you would deal with that the same way you do now when combining packages that define their own command-line flag parsing in a non-test program—by manually fixing those collisions when they occur.

Contributor

josharian commented May 13, 2015

I would think that you would deal with that the same way you do now when combining packages that define their own command-line flag parsing in a non-test program—by manually fixing those collisions when they occur.

@andrewchambers

This comment has been minimized.

Show comment
Hide comment
@andrewchambers

andrewchambers May 13, 2015

@josharian wrt name spacing, The full package path could be part of the test name, or there could be a seperate flag -runpkg that works in conjunction with -run.

@josharian wrt name spacing, The full package path could be part of the test name, or there could be a seperate flag -runpkg that works in conjunction with -run.

@josharian

This comment has been minimized.

Show comment
Hide comment
@josharian

josharian May 14, 2015

Contributor

Another challenge (just writing them down here as I think of them) -- tests are supposed to be executed from the directory in which they are written. This lets them find fixtures easily. However, if multiple tests are bundled into a single executable, there is no single correct working directory. Again, not a showstopper, just something to be thought through.

Contributor

josharian commented May 14, 2015

Another challenge (just writing them down here as I think of them) -- tests are supposed to be executed from the directory in which they are written. This lets them find fixtures easily. However, if multiple tests are bundled into a single executable, there is no single correct working directory. Again, not a showstopper, just something to be thought through.

@tv42

This comment has been minimized.

Show comment
Hide comment
@tv42

tv42 May 14, 2015

@josharian Please don't rely on that. go test -c github.com/jdoe/foo is a thing, and so is cross-compiling & rsyncing the test binary.

tv42 commented May 14, 2015

@josharian Please don't rely on that. go test -c github.com/jdoe/foo is a thing, and so is cross-compiling & rsyncing the test binary.

@tv42

This comment has been minimized.

Show comment
Hide comment
@tv42

tv42 May 14, 2015

@josharian Or maybe I should say, don't rely on that in general. It's fine for a lone project to decide it has more onerous requirements; that doesn't make those requirements of go test itself.

tv42 commented May 14, 2015

@josharian Or maybe I should say, don't rely on that in general. It's fine for a lone project to decide it has more onerous requirements; that doesn't make those requirements of go test itself.

@josharian

This comment has been minimized.

Show comment
Hide comment
@josharian

josharian May 14, 2015

Contributor

@tv42 that is how the go tool works right now, there are many tests in the standard library that rely on that (try e.g. go test -c net && mv net.test /tmp && /tmp/net.test), and as far as I know, it is the recommended way to make fixtures available for tests. For the record, I have cross-compiled and scp'd tests more times than I would like. The point is just that this is useful behavior that was intentionally designed; I would not give it up lightly.

Contributor

josharian commented May 14, 2015

@tv42 that is how the go tool works right now, there are many tests in the standard library that rely on that (try e.g. go test -c net && mv net.test /tmp && /tmp/net.test), and as far as I know, it is the recommended way to make fixtures available for tests. For the record, I have cross-compiled and scp'd tests more times than I would like. The point is just that this is useful behavior that was intentionally designed; I would not give it up lightly.

@minux

This comment has been minimized.

Show comment
Hide comment
@minux

minux May 14, 2015

Member
Member

minux commented May 14, 2015

caarlos0 added a commit to getantibody/antibody that referenced this issue Jun 12, 2015

@robpike

This comment has been minimized.

Show comment
Hide comment
@robpike

robpike Jul 23, 2015

Contributor

I just tried

go test --coverprofile foo --coverpkg ./...
go tool cover -html foo

and pulled up a web page with coverage data from all the packages in the tree. However, it was created only by running tests in the current directory, not the dependent ones. That is, it contains coverage information for all the packages that were used in running the tests for this package.

So, it's not clear but I believe the request that one should be able to do

go test --coverprofile foo --coverpkg ./... ./...

(note the extra ./...). The issue title is therefore incorrect, and I will address that.

As for fixing the issue, it seems to me that an external tool that merges a set of profiles is easy to do. I don't see much need for doing. this within go test itself.

Contributor

robpike commented Jul 23, 2015

I just tried

go test --coverprofile foo --coverpkg ./...
go tool cover -html foo

and pulled up a web page with coverage data from all the packages in the tree. However, it was created only by running tests in the current directory, not the dependent ones. That is, it contains coverage information for all the packages that were used in running the tests for this package.

So, it's not clear but I believe the request that one should be able to do

go test --coverprofile foo --coverpkg ./... ./...

(note the extra ./...). The issue title is therefore incorrect, and I will address that.

As for fixing the issue, it seems to me that an external tool that merges a set of profiles is easy to do. I don't see much need for doing. this within go test itself.

@robpike robpike changed the title from x/tools/cmd/cover: should support -coverprofile for multiple packages to x/tools/cmd/cover: should support -coverprofile unifying tests from multiple packages Jul 23, 2015

@pierrre

This comment has been minimized.

Show comment
Hide comment
@wadey

This comment has been minimized.

Show comment
Hide comment
@wadey

wadey Jul 23, 2015

Contributor

I've written a tool to properly merge coverprofiles that doesn't just blindly cat them together. It uses golang/x/tools/cover to parse the files and outputs a merged version back to stdout:

https://github.com/wadey/gocovmerge

It's still a work in progress, but it is working great for our repos.

We combine with a generic Makefile that runs go test -coverprofile … -coverpkg (all same repo dependencies) … for each folder in a repo. If anyone is interested in that Makefile I can clean it up and post it as well.

Contributor

wadey commented Jul 23, 2015

I've written a tool to properly merge coverprofiles that doesn't just blindly cat them together. It uses golang/x/tools/cover to parse the files and outputs a merged version back to stdout:

https://github.com/wadey/gocovmerge

It's still a work in progress, but it is working great for our repos.

We combine with a generic Makefile that runs go test -coverprofile … -coverpkg (all same repo dependencies) … for each folder in a repo. If anyone is interested in that Makefile I can clean it up and post it as well.

@joeybloggs

This comment has been minimized.

Show comment
Hide comment
@joeybloggs

joeybloggs Aug 4, 2015

I create a library that may help, https://github.com/bluesuncorp/overalls

all it does is recursively go through each directory ( aka each package ), run go test and produce coverprofiles, then merges all profiles into a single one at the root of the project directory called overalls.coverprofile

then you can use a tool like https://github.com/mattn/goveralls to send it to coveralls.io

I create a library that may help, https://github.com/bluesuncorp/overalls

all it does is recursively go through each directory ( aka each package ), run go test and produce coverprofiles, then merges all profiles into a single one at the root of the project directory called overalls.coverprofile

then you can use a tool like https://github.com/mattn/goveralls to send it to coveralls.io

@pierrre

This comment has been minimized.

Show comment
Hide comment
@pierrre

pierrre Aug 4, 2015

@wadey @joeybloggs Did you used my tool before creating your own tool?
https://github.com/pierrre/gotestcover

pierrre commented Aug 4, 2015

@wadey @joeybloggs Did you used my tool before creating your own tool?
https://github.com/pierrre/gotestcover

@wadey

This comment has been minimized.

Show comment
Hide comment
@wadey

wadey Jan 18, 2017

Contributor

@joeybloggs unless I'm missing something it looks like go-playground/overalls does not do smart merging of the profiles (like gocovmerge) and just dumps all of the output into one file (see here https://github.com/go-playground/overalls/blob/dab02cad1edafb5aa1d38729ba4bfd5618b836ce/overalls.go#L295-L297 ) This means it won't handle overlaps in coverage correctly.

Contributor

wadey commented Jan 18, 2017

@joeybloggs unless I'm missing something it looks like go-playground/overalls does not do smart merging of the profiles (like gocovmerge) and just dumps all of the output into one file (see here https://github.com/go-playground/overalls/blob/dab02cad1edafb5aa1d38729ba4bfd5618b836ce/overalls.go#L295-L297 ) This means it won't handle overlaps in coverage correctly.

@joeybloggs

This comment has been minimized.

Show comment
Hide comment
@joeybloggs

joeybloggs Jan 18, 2017

@wadey I've never had a problem before, thanks I'll look into it; it seems pretty trivial to implement.

@wadey I've never had a problem before, thanks I'll look into it; it seems pretty trivial to implement.

@nathany

This comment has been minimized.

Show comment
Hide comment
@nathany

nathany Jan 19, 2017

Contributor

Thanks @wadey. The goverage tool from @haya14busa is looking good and was easy to set up.

Contributor

nathany commented Jan 19, 2017

Thanks @wadey. The goverage tool from @haya14busa is looking good and was easy to set up.

@LukeShu

This comment has been minimized.

Show comment
Hide comment
@LukeShu

LukeShu Feb 8, 2017

@wadey I've created my own tool, gocovcat that looks like it does the same thing as yours. It doesn't keep track of the order of blocks (which I think yours does), but it seems a bit simpler. If you're the type of person who enjoys comparing different solutions.

LukeShu commented Feb 8, 2017

@wadey I've created my own tool, gocovcat that looks like it does the same thing as yours. It doesn't keep track of the order of blocks (which I think yours does), but it seems a bit simpler. If you're the type of person who enjoys comparing different solutions.

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Jun 14, 2017

Contributor

The big problem with all the workarounds is that on larger repositories the time to run coverage is prohibitively slow. I'm working on a repo where unit tests run in 12 seconds using go test <list of packages>. Running each package separately (even without coverage) increases the test time to 200 seconds (the runtime is about the same with coverage enabled).

I'd like to contribute a fix for this issue. Looking at the patch from a few years ago and some experimenting I've done, it doesn't seem to be a difficult thing to fix.

This single 1 line change allows go test --coverprofile ... to run with multiple packages:

diff --git a/src/cmd/go/internal/test/testflag.go b/src/cmd/go/internal/test/testflag.go
@@ -164,7 +164,7 @@ func testFlags(args []string) (packageNames, passToTest []string) {
 				}
 			case "coverprofile":
 				testCover = true
-				testProfile = true
 			case "covermode":
 				switch value {
 				case "set", "count", "atomic":

The profiles are written to a file in the same directory as the package. It seems like what might be missing is support for multiple files in go tool cover, including merging of multiple profiles when there are overlaps.

Anything else that would need to change?

Contributor

dnephin commented Jun 14, 2017

The big problem with all the workarounds is that on larger repositories the time to run coverage is prohibitively slow. I'm working on a repo where unit tests run in 12 seconds using go test <list of packages>. Running each package separately (even without coverage) increases the test time to 200 seconds (the runtime is about the same with coverage enabled).

I'd like to contribute a fix for this issue. Looking at the patch from a few years ago and some experimenting I've done, it doesn't seem to be a difficult thing to fix.

This single 1 line change allows go test --coverprofile ... to run with multiple packages:

diff --git a/src/cmd/go/internal/test/testflag.go b/src/cmd/go/internal/test/testflag.go
@@ -164,7 +164,7 @@ func testFlags(args []string) (packageNames, passToTest []string) {
 				}
 			case "coverprofile":
 				testCover = true
-				testProfile = true
 			case "covermode":
 				switch value {
 				case "set", "count", "atomic":

The profiles are written to a file in the same directory as the package. It seems like what might be missing is support for multiple files in go tool cover, including merging of multiple profiles when there are overlaps.

Anything else that would need to change?

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Jun 14, 2017

Contributor

I'm working on a repo where unit tests run in 12 seconds using go test . Running each package separately (even without coverage) increases the test time to 200 seconds (the runtime is about the same with coverage enabled).

If this is true then the problem here is that when you run go test it is rebuilding the test packages' dependencies over and over. You can fix that by first doing 'go test -i ', which installs all the prerequisite packages, so that the separate command reuse them. My plan is that in Go 1.10 the go command will cache build results more aggressively so that the 'go test -i' step will not be necessary for the two ways to run in the same amount of time. But we're not there today.

Contributor

rsc commented Jun 14, 2017

I'm working on a repo where unit tests run in 12 seconds using go test . Running each package separately (even without coverage) increases the test time to 200 seconds (the runtime is about the same with coverage enabled).

If this is true then the problem here is that when you run go test it is rebuilding the test packages' dependencies over and over. You can fix that by first doing 'go test -i ', which installs all the prerequisite packages, so that the separate command reuse them. My plan is that in Go 1.10 the go command will cache build results more aggressively so that the 'go test -i' step will not be necessary for the two ways to run in the same amount of time. But we're not there today.

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Jun 14, 2017

Contributor

Thanks! -i cuts the run time down to 34 seconds. Still slower than running all packages at once, but much better overall.

Contributor

dnephin commented Jun 14, 2017

Thanks! -i cuts the run time down to 34 seconds. Still slower than running all packages at once, but much better overall.

@oshalygin

This comment has been minimized.

Show comment
Hide comment
@oshalygin

oshalygin Jul 3, 2017

@dnephin I like the approach, any thoughts on whether or not this would be considered?

@dnephin I like the approach, any thoughts on whether or not this would be considered?

@dlsniper

This comment has been minimized.

Show comment
Hide comment
@dlsniper

dlsniper Jul 17, 2017

Contributor

@rsc I would be happy to work on this for 1.10, provided anything required by this is in place by then. Any guidance from you or anyone else would be good. Also this can have the IDE label as well.

Contributor

dlsniper commented Jul 17, 2017

@rsc I would be happy to work on this for 1.10, provided anything required by this is in place by then. Any guidance from you or anyone else would be good. Also this can have the IDE label as well.

@AlekSi

This comment has been minimized.

Show comment
Hide comment
@AlekSi

AlekSi Jul 25, 2017

Contributor

In the mean time, I made another tool: https://github.com/AlekSi/gocoverutil. Unlike some bash scripts mentioned there, it sets exit status correctly if tests fail, it sets -coverpkg to include all packages, etc.
But I'm really looking forward to retiring it when this issue and #21126 are closed.

Contributor

AlekSi commented Jul 25, 2017

In the mean time, I made another tool: https://github.com/AlekSi/gocoverutil. Unlike some bash scripts mentioned there, it sets exit status correctly if tests fail, it sets -coverpkg to include all packages, etc.
But I'm really looking forward to retiring it when this issue and #21126 are closed.

@tleyden tleyden referenced this issue Oct 20, 2017

Closed

Improve code coverage report #2937

5 of 7 tasks complete
@rasky

This comment has been minimized.

Show comment
Hide comment
@rasky

rasky Nov 6, 2017

Contributor

@rsc now that the build cache is in, are we closer to fix this bug? I think people are waiting here for some guidance on how to fix it. I can attempt something myself, but it would be great if you could provide some guidance. Thanks!

Contributor

rasky commented Nov 6, 2017

@rsc now that the build cache is in, are we closer to fix this bug? I think people are waiting here for some guidance on how to fix it. I can attempt something myself, but it would be great if you could provide some guidance. Thanks!

@dlsniper

This comment has been minimized.

Show comment
Hide comment
@dlsniper

dlsniper Nov 6, 2017

Contributor

Maybe a different way to see the problem is that we should have a different covermode for which we can apply this feature.

For example, running go test -coverprofile=coverage.out ./... should detect that the user wants to run in a recursive mode thus set the covermode to a recursive (or better named mode) in which, regardless of how many times a line is executed, it counts only as a simple boolean value (yes / no)?

Contributor

dlsniper commented Nov 6, 2017

Maybe a different way to see the problem is that we should have a different covermode for which we can apply this feature.

For example, running go test -coverprofile=coverage.out ./... should detect that the user wants to run in a recursive mode thus set the covermode to a recursive (or better named mode) in which, regardless of how many times a line is executed, it counts only as a simple boolean value (yes / no)?

@dlsniper

This comment has been minimized.

Show comment
Hide comment
@dlsniper

dlsniper Nov 6, 2017

Contributor

Of course, this could also be done in a more complex way, by storing which test hit which line and then, on a per-line basis, and then offer for each line of code touched by tests a slice of test names. It would then be up to the tools to read that information and display it to the users, in the most simplistic way doing this as described above with a simple yes / no mode.

Sorry for the double message.

Contributor

dlsniper commented Nov 6, 2017

Of course, this could also be done in a more complex way, by storing which test hit which line and then, on a per-line basis, and then offer for each line of code touched by tests a slice of test names. It would then be up to the tools to read that information and display it to the users, in the most simplistic way doing this as described above with a simple yes / no mode.

Sorry for the double message.

@andradei

This comment has been minimized.

Show comment
Hide comment
@andradei

andradei Nov 7, 2017

The first suggestions is a great way to get this started. But the more powerful and resourceful go test -converprofile is , the better.

andradei commented Nov 7, 2017

The first suggestions is a great way to get this started. But the more powerful and resourceful go test -converprofile is , the better.

@gopherbot

This comment has been minimized.

Show comment
Hide comment
@gopherbot

gopherbot Nov 10, 2017

Change https://golang.org/cl/76875 mentions this issue: cmd/go: allow -coverprofile with multiple packages being tested

Change https://golang.org/cl/76875 mentions this issue: cmd/go: allow -coverprofile with multiple packages being tested

@rsc rsc modified the milestones: Unreleased, Go1.10 Nov 10, 2017

@rsc rsc changed the title from x/tools/cmd/cover: should support -coverprofile unifying tests from multiple packages to cmd/cover: should support -coverprofile unifying tests from multiple packages Nov 10, 2017

@gopherbot gopherbot closed this in 283558e Nov 10, 2017

@at15 at15 referenced this issue May 4, 2018

Closed

[test] Enable test coverage #39

0 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment