Editor’s note:

“Planet of the Gorilla” is a content sharing segment focusing on the technology field. We will invite cloud computing industry giants from various enterprises from time to time to share technology content here and build the prosperity of the industry. In this episode, we’re happy to have you

Qiniuyun business efficiency Department head Big Carl
. He’s going to share with us
Goc, the Go Language System Test coverage Collector
.

In the field of engineering effectiveness, measurement of test coverage is always a topic, and we are no exception. At Qiniuyun, we mainly use go language to build cloud services, and when considering system test coverage, we first built around native Go test-C-Cover capabilities. And we have done a lot of automation work, which can automatically generate TestMain() and other methods for many types of code bases, automatically pile services, but with the increasing number of access projects and the increasing complexity of subsequent use scenarios, we find that this scheme still has its inherent limitations, which will make the future more and more uncomfortable:

  • Programs must be closed to collect coverage. This pain point would be tolerable if the system were focused solely on collecting coverage data. But if you want to do more accurate testing and other directions, it is very limited.

  • Not wanting to contaminate the code base under test, we automate the process by generating a file like main_test.go for each service during compilation. The hardest part of this approach, however, is the handling of the flag. The go test command itself calls flag.Parse, so you need to automatically modify the source code to ensure that the flag of the program under test is defined before go Test calls flag.Parse. However, as the program gets more complicated using flag poses on its own, we find it harder and harder to come up with a general solution for dealing with these flags, somewhat uncomfortably.

  • Due to the inherent defect of the go test-c command, it injects test specific flags into the program under test, such as -test.coverprofile, -test.timeout, etc. This one is the most uncomfortable because it disrupts the startup position of the program under test. We know that system testing is a complete cluster under test, and if you need to maintain a dedicated set of test clusters for coverage collection, it can be very wasteful. Good steel should be used on the edge of the knife. At Qiniuyun, we advocate geek culture and pursue to solve repetitive problems with engineer’s thinking. As a business efficiency department, we should take the lead.

As a result of these considerations, we have been optimizing the system internally, and with today’s release, we have revolutionized the architecture and implementation principles, enabling non-destructive pile-insertion and runtime analysis coverage, which is very elegant.

Goc – A Comprehensive Coverage Testing System for The Go Programming Language

Using the goc run. Pose to directly run the program under test, you can easily get coverage results at runtime using the GOC profile command. Isn’t that amazing? Isn’t it elegant?

This system is CALLED GOC. In terms of design and use experience, we hope to be close to go core commands (go build/install/run) to improve user experience. Here’s a list of the latest supported features:

System test coverage collection plan

With GOC in mind, let’s look at how to collect go system test coverage. The whole is relatively simple, roughly only need three steps:

  • First deploy a service registry using the GOC Server command, which will act as the hub service to communicate with all the services under test.

  • Compile the program under test using the goc build–center=”

    ” command. Goc does not break the startup mode of the application under test, so you can publish the compiled binary directly to the integration test environment.

  • Once the environment is deployed, any system tests can be performed. The goC profile–center=”

    ” can be used to get the coverage results of the current cluster under test at any time during the test.

Isn’t it elegant?

Goc core principles and future

In terms of design, GOC abandoned the old GO test-c-cover mode and directly interoperated with go Tool Cover to avoid a series of disadvantages introduced by go test command. Goc also chose not to do its own plugins, due to go language compatibility and performance concerns. After all, the Go Tool Cover tool uses a native structure to define the counter collector. Each file has a separate structure, and the performance is relatively reliable. Goc aims to be a comprehensive coverage tool and accurate testing system for the GO language. It still has a long way to go:

  • Analysis of single test/set test/system coverage increment based on PR

  • Precise test direction, with a certain product design experience, convenient for research and development and test daily use

  • Embrace the various CICD systems

Goc is currently open source (github.com/qiniu/goc)

If you are interested, please visit the code repository for details and Star support. Of course, we welcome people who are willing to contribute and build this interesting system with us.