If you’re not writing tests for your code you should start right away. Writing tests not only makes sure that your codes are working the way they should, it is also a great way of thinking objectively about your class and functions. It may also lead you to write better code as a result.
But I’m not going to teach you how to write testable code as there are tons of high quality material on that out there. What we’re going to talk about here is Code Coverage and what it implies and how to use it in Go.
Code Coverage shows how much of your code base is taking part in your tests. In other words it shows that with how much confidence you can say that your code is tested.
A low coverage is certainly an indication that not enough tests have been written to test every aspect of your code. A high coverage can indicate that your tests have been exhaustive enough to test most of your code base.
Finding out the Code Coverage is certainly not something that can be done manually and there are tools for that. In Go as with many other tasks there is an excellent tool in the Go’s toolchain.
What we’re going to use here are the
go test and the
go tool cover commands. As a sample I’m going to use this open source project of mine to run these tools.
A linux task manager meant to replace crontab. Contribute to 2hamed/goronos development by creating an account on…
The project uses Go Modules so in order to use it you should have at least Go v1.12 installed on your machine.
First and foremost run the
go mod tidy to install the dependencies. As you can see most of the code is located under the
scheduler package and we are going to run our tests on that package. To run the tests execute the following command in the project’s root folder:
go test ./scheduler
As you can see it prints the result of our tests on stdout (and one test is failing but it doesn’t matter right now). So what about the coverage?
To get the code coverage we need to add another part to our test command and it is as follows:
go test --coverprofile ./scheduler/.coverage ./scheduler
By specifying the
--coverprofile ./scheduler/.coverage parameter we tell the test tool to write the code coverage result in the file
./scheduler/.coverage . Let’s take a look at what is produces.
github.com/2hamed/goronos/scheduler/utils.go:17.51,19.21 1 1
github.com/2hamed/goronos/scheduler/utils.go:23.2,23.29 1 1
github.com/2hamed/goronos/scheduler/utils.go:28.2,28.14 1 1
github.com/2hamed/goronos/scheduler/utils.go:19.21,21.3 1 1
github.com/2hamed/goronos/scheduler/utils.go:23.29,24.13 1 1
github.com/2hamed/goronos/scheduler/utils.go:24.13,26.4 1 1
github.com/2hamed/goronos/scheduler/utils.go:32.73,34.21 1 1
github.com/2hamed/goronos/scheduler/utils.go:38.2,38.29 1 1
github.com/2hamed/goronos/scheduler/utils.go:43.2,43.14 1 1
github.com/2hamed/goronos/scheduler/utils.go:34.21,36.3 1 1
github.com/2hamed/goronos/scheduler/utils.go:38.29,39.13 1 1
github.com/2hamed/goronos/scheduler/utils.go:39.13,41.4 1 1
github.com/2hamed/goronos/scheduler/utils.go:47.76,48.21 1 1
Well I can tell you that is not helpful at all. And here comes the other tool that we spoke of. Let’s run the following command next:
go tool cover -html ./scheduler/.coverage
Running that command should open your browser with something like the following image inside it:
This certainly is useful as it displays your files distinctively with all their code and where they stand in your tests. Whether they are covered or not. You can even save this file as an HTML by supplying the
-o param with the output file address.
Using this tool you can detect the paths that are not covered by your tests and you should write additional tests to cover them as well.
Writing good tests takes practice and what is required to write good tests is writing good (testable) code. By using code coverage you can make sure that you’re considering every aspect of your code and it all leads to a better software.
Be sure to leave a clap on this post if you find it useful. You’re also welcome to visit my Github profile and checkout the projects I’m currently working on and you’re more than welcome to make pull requests on them.