Furthermore, if your application exits with panic or with os.Exit(code int), go test won’t collect coverage information.
For one, it’s impossible to pass in command line arguments, which for products such as the Confluent CLI is critical. Unfortunately, instrumenting a binary in this way is too simplistic for several reasons. It’s as easy as it sounds: // +build testrunmain This test is then compiled using a build tag to prevent the file from being included in the package when built normally, and the resulting instrumented binary is executed to generate a coverage profile. The main idea behind measuring Go binary coverage, introduced in the previously mentioned Elastic blog, is to create a file with a “fake” test that runs the main method of the application.
#Goland test coverage how to#
This deep dive covers how we’ve implemented Bincover and shows a demo on how to use it to measure the coverage of a simple Go application. We’ve open sourced a tool called Bincover, which solves this problem by providing a simple and flexible API that generates an “instrumented binary” that can measure its own coverage, runs it with user-specified command line arguments and environment variables, and merges coverage profiles generated from multiple test runs. Until we wrote Bincover, there was no tool to measure binary coverage that satisfied these requirements and could be easily integrated with our existing code.
In addition, our code needs to be robust enough to handle panics and OS exits, and products like the Confluent CLI and Confluent Cloud CLI, which are written in Go, need to parse command line arguments. A blog post published by Elastic presents a clever solution to this problem, but it doesn’t include a ready-to-use, generic solution.Īt Confluent, many of our system and integration tests are written in Go. Measuring coverage of Go code is an easy task with the built-in go test tool, but for tests that run a binary, like end-to-end tests, there’s no obvious way to measure coverage.
0 kommentar(er)
