Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use goc, a sharp tool for test coverage collection in go language systems, and the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

In the field of engineering efficiency, test coverage measurement is always an unavoidable topic, and we are no exception. At Qiniuyun, we mainly use the go language to build cloud services. When considering the system test coverage, we first built it around the capabilities of native go test-c-cover. And we have done a lot of automation work, which can be used for many types of code base, automatic stuffing service, automatic generation of TestMain () and other methods. However, with more and more access projects and the increasing complexity of subsequent usage scenarios, we find that this solution still has its inherent limitations, which will make the following more and more difficult:

The program must be closed to collect coverage. If the system is only focused on collecting coverage data, this pain point can be tolerated. But if you want to do more accurate testing and other directions, it is very limited.

Because we don't want to pollute the code base under test, we take an automated approach by generating similar main_test.go files for each service during the compilation phase. But in this way, the most uncomfortable part is the processing of flag, knowing that the go test command itself will call the flag.Parse method, so here we need to automatically modify the source code to ensure the flag definition of the program under test, before go test calls flag.Parse. However, as the program complicates its own use of flag postures, we find it a bit uncomfortable to have a general solution to deal with these flag.

Due to the inherent defects of the go test-c command, it will inject some test-specific flag into the program under test, such as-test.coverprofile,-test.timeout, and so on. This is the hardest because it destroys the startup posture of the program being tested. We know that the system test is a complete cluster under test, and it will be very wasteful if you need to maintain a special test cluster for coverage collection. Good steel should be used on the cutting edge, in Qiniuyun, we advocate geek culture, pursue to solve repetitive problems with engineer thinking, and as a business efficiency department, we should be in the forefront.

It is also because of the above considerations that we have been optimizing this system internally. Up to this edition, we have completed the subversion in terms of architecture and implementation principle. It is very elegant to be able to insert piles without loss and run-time analysis coverage.

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

A picture is worth a thousand words:

Use goc run. If you run the program under test directly, you can easily get the coverage results through the goc profile command at run time. Isn't that amazing? Isn't it elegant?

This system is called goc and is designed to be fully compatible with go command-line tool core commands (go build/install/run). In terms of experience, I also want to be close to go command-line tools. The following features are supported in goc version 1.0:

System test coverage collection scheme

With goc, let's look at how to collect test coverage for go language systems. As a whole, it is relatively simple, and it takes only three steps:

First, deploy a service registry through the goc server command, which will communicate with all the tested services as a hub service.

Use the goc build--center= "" command to compile the program under test. Goc does not break the way the program under test starts, so you can publish the compiled binaries directly to the integrated test environment.

Once the environment is deployed, you can perform arbitrary system tests. During the test, you can get the coverage results of the current tested cluster through goc profile--center= "" at any time.

Isn't it elegant?

The Core principle and Future of goc

In design, goc abandons the old go test-c-cover mode and interacts directly with go tool cover tools to avoid a series of disadvantages introduced by go test commands. Goc also did not choose to do its own stake, but also consider the compatibility of the go language, as well as performance issues, after all, go tool cover tools, native use structure to define the counter collector, each file has a separate structure, the performance is relatively reliable. Goc aims to be a comprehensive coverage tool and accurate testing system in the field of go language, and it still has a long way to go:

Incremental Analysis of single Test / centralized Test / system coverage based on PR

Accurate testing direction, have a certain product design experience, convenient for R & D and testing for daily use

Embrace all kinds of CICD systems

On the go language system test coverage collection tool goc how to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.