Re:Code coverage for Go integration tests
by FiloSottile on Wednesday March 08, 2023 @06:52PM
(#35076407)
No idea if the technique was original, it’s been too long, but I wrote about it on the Cloudflare blog in 2016. https://blog.cloudflare.com/go-coverage-with-external-tests/
Anyway, very happy to see the team ship first class support for it. It immediately made coverage support in testscript much more natural, too. https://github.com/rogpeppe/go-internal/pull/201
Elastic wrote about that in 2015: https://www.elastic.co/blog/code-coverage-for-your-golang-sy.... I guess multiple people figured it out independently.
Re:Code coverage for Go integration tests
by eliben on Wednesday March 08, 2023 @11:15PM
(#35078264)
Yes, technically you could wrap every `main` in a test and build everything just right, but it's nice to be able to do this without any hacks if you already have an integration test suite and you want to know what coverage it gets you.
Here's an example of the build step: https://github.com/multiprocessio/datastation/blob/main/runn....
And here's how I'd analyze coverage after using the binary: https://github.com/multiprocessio/datastation/blob/main/runn.... This analysis actually combined both unit test coverage files with integration test coverage so it gave a pretty good overall indication of code paths covered by any tests.
I can't remember where I found this technique but it's been around for a while.
This new option is the same thing but a way to `go build` with `-cover` instead of `go test -cover -o $out`? Do I have that right?
Another example of doing this from 2019: https://stackoverflow.com/a/55640874/1507139. I'm sure I learned about this from somebody's blog but I can't remember where.