Building and Testing Go with GoClipse, and Coveralls

Dec 09, 2015

In a previous article I showed building table-driven tests in Go. I then added another article to cover testing error conditions. Now that we have tests that cover all the cases, we deserve to get some green badges on our GitHub repository.

To help illustrate these articles with a simple example, I’ve posted a repository on GitHub that converts Roman numerals in string form into the numeric equivalent. I’ve added build support using, and code coverage using Coveralls.

Before we get there, it’s worth pointing out that Go has built-in support for test code coverage. Here are the commands to fetch a code repository and run its tests in verbose mode with code coverage enabled:

go get
go test -v --cover

This produces the following output:

=== RUN   TestValid
--- PASS: TestValid (0.00s)
=== RUN   TestInvalid
--- PASS: TestInvalid (0.00s)
coverage: 100.0% of statements
ok   0.009s

I’ve been using GoClipse, as I’m already familiar with Eclipse coming from Java. It’s built on Eclipse C/C++ Development Tools and can be configured with a little effort to do source code debugging, though mostly I like it for code completion and a familiar keyboard shortcut that runs gofmt.

Because compiling and testing in Go is so fast, I configure GoClipse to run tests with code coverage on every save. This means I get instant feedback not just on compile errors, but also on whether I’ve broken unit tests and how I’m doing on coverage. Here’s what that looks like:

Here I’ve customized the “run-tests” target to include “-cover”. Also note the small blue checkmark on the “run-tests” entry in the Project Explorer; this indicates that this build target will run automatically as part of the workspace build.

Now, to get those green badges. Adding a Go project to from a GitHub repository is a matter of logging in using GitHub credentials, authorizing the application, clicking New Project, and selecting the repository. The badge link in Markdown (under Settings / Status Badges) can be added to the file at the root of the Git repository. This will cause GitHub to display a status badge for the build.

To get a code coverage badge, I used Coveralls with goveralls. The goveralls README provides instructions for First, visit Coveralls, sign in using GitHub, and authorize. Then, enable the repository. Copy the repo token from the right side of the repository details page, and paste it into the Environment Variables settings on for the repository (under Settings / Build & Test):

COVERALLS_TOKEN=(paste token here)

Finally, change the build commands to be:

go get
go build

go get
go get
goveralls -service

As with, the Coveralls repository page provides a Markdown link for a readme badge. Once everything is done, and the updated is pushed to GitHub, the GitHub page should show something like this:

These badges will update automatically when new changes are pushed. In addition to the badges, and Coveralls will keep detailed information on builds; for an example, see the build history and Coveralls build history for my Roman numeral repository.

Now that these tools are up and running they are a great help in repository management. Both tools can be configured to send email alerts, as well as build pull requests and report back results to the pull request itself. Coveralls will even let you configure a threshold for coverage decrease in order to automatically fail a pull request that adds too much untested code.