Now that we’ve explained the general approach of how Bincover instruments a binary, let’s see how Bincover can be used to measure coverage of an actual Go application. Note that you can rename TestBincoverRunMain and the build tag as desired. A detailed discussion on this topic can be found in this golang-nuts thread.
#GOLAND CODE COVERAGE FULL#
Including the package name is necessary when adding linker flags in tests, since go test renames the package being tested and passes the value to a nonexistent package if the full name isn’t specified. Linker flags can be specified with -ldflags="path/to/main-function.key=value". path/to/main-function -tags testbincover -coverpkg=./.
The above file can be compiled with go test.
This is problematic for applications that exit with a non-zero exit code by design, like a CLI when an invalid command is run.īincover handles all of these problems while requiring no additional lines of code to do so: // +build testbincover 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 CODE 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)
