Testing in Go: philosophy and tools

Posted May 26, 2020 18:50 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Parent article: Testing in Go: philosophy and tools

> Go test's -cover mode produces code coverage profiles that can be viewed as HTML
Go coverage analysis SUCKS. Seriously.

For example, it's impossible to do code coverage for integration tests or for manual tests. There are workarounds like writing a fake test that just runs the project's true "func main", but it's not enough for many reasons.

I've looked into trying to add ability to instrument non-test code, but the underlying rewriter is a freaking mess that is not modular and can't be easily extracted without major surjery.

Testing in Go: philosophy and tools

Posted May 26, 2020 19:19 UTC (Tue) by benhoyt (subscriber, #138463) [Link] (1 responses)

Interesting. I'd love to know more about this; any links? Our team at work has recently started running integration tests using the regular testing package and it seems to work well, but these are fairly lightweight "PostgreSQL database only" integration tests, not "run all the services" integration tests.

Testing in Go: philosophy and tools

Posted May 26, 2020 22:33 UTC (Tue) by phlogistonjohn (subscriber, #81085) [Link]

Here's an example of wrapping the main function in a test to get coverage.

I have to second Cyberax's comment. Last time I looked into this it quickly became too complicated to deal with, and I didn't need it very much and gave up. I too peeked at the code to implement this and it was too complex for me to follow (having been doing Go mostly full time for a year or so).

It's rather unfortunate that this isn't a feature of the compiler and say a helper module you can import into your own main. I lean heavily normal on the coverage feature for tests in a few of the projects I work on. I would love to have a simple, noninvasive way to generate coverage from any binary.

Testing in Go: philosophy and tools

Posted May 26, 2020 22:57 UTC (Tue) by cyphar (subscriber, #110703) [Link]

While it isn't ideal, I did manage to implement coverage testing of integration tests for a moderately sized project in Go -- I even wrote a blog post about it[1]. Yes, you do have some boilerplate to put inside a TestXxx() function in order to get it to work, but that's a fairly fixed cost.

[1]: https://www.cyphar.com/blog/post/20170412-golang-integrat...