coverage testing in the Golang
Golang provides a number of tool chains that can be used to facilitate unit testing, analyze performance bottlenecks, provide runtime information, and so on, all of which are useful.
Go test This tool people should use more, I used to do mostly for unit testing, go to do unit testing is very convenient, but I ignored the coverage test.
How much code does the unit test cover? Golang's Go test tool also supports display coverage, and the simplest use is to perform
Go test-c-covermode=count-coverpkg/...
To compile an executable file with the suffix. Test, after execution, it executes all the unit test code and then outputs the coverage report.
This is actually the coverage of the statistical unit test, which is the coverage of the white box test.
However, our functional test here tells me that this also supports the black box test coverage statistics, I was still a bit stunned, think it is unlikely. So the test sent me the following article, I read the next, really brain hole, really want to come out.
Article
According to this article, in a unit test file, define a function that, when a flag is provided, executes the main function to run the primary loop.
Package main
import (
"flag"
"testing" "
Github.com/cihub/seelog"
)
var systemtest *bool
var testconfigpath *string
func init () {
systemtest = flag. Bool ("Systemtest", False, "Set to True when running system tests")
Testconfigpath = flag. String ("Configpath", "", "-configpath <lua config file path>")
}
func testentry (t *testing. T) {
// system tests?
Flag. Parse ()
if *systemtest {
seelog. Info ("System test running Main")
// Set the Configpath variable
g_configpath = Testconfigpath
Main ()
}
}
Of course, my ontology program itself has an input parameter, here do a little trick, in the Init function to parse the parameters, assuming that the original parameters are parsed, then assign to main parameter variables, main will determine whether this variable is initialized, if not, will be again the flag read.