Continuous Integration (incl. unit tests and test coverage) for open source projects in GitHub with travisCI and coveralls.


Some time ago, we released the first version of a yeoman generator for Node.js projects: generator-next

Although our project is in a very early stage, we always care about code quality. But how can we maintain a high level of code quality while simultaneously allowing basically all GitHub users to contribute? One concept that always pops up in these discussions is Continuous Integration. CI, in theory, allows us to improve the overall quality of code by continuously (and frequently) integrating new changes into the existing code base and running automated tests after the integration to verify that no functionality was broken.

There are various tools (e.g. Bamboo, Jenkins, TeamCity, GitLab, Team Foundation Server) supporting CI with a wide range of features.

In our case, we wanted to achieve the following:

  • run unit-tests automatically in different environments (different Node.js versions in our case)
  • Generate a coverage report and enable developers to analyze it
  • Make build and test results accessible to all developers, contributors and users

Getting started with TravisCI 

One of the most famous CI tools for GitHub projects is TravisCI. Completely free for open source projects and having a promising documentation, this was the CI tool we decided for. Only a few clicks later, the connection with our GitHub repository was established. In contrast to some other CI tools, most of the configuration is done in a single file, typically called .travis.yml

With only 5 lines of code in this configuration file, we are able to: Install dependencies, run tests on different environments, publish coverage to coveralls.

Specifying “node_js” as language enables the default configuration for node_js projects, which is npm install (installing all the dependencies) followed by npm test (run our unit tests and generate coverage). Line 2 to 5 specifies which Node.js versions we want to test. In our case, we want to support the latest releases of Versions 7, 8 and the latest stable release (9.x.x) which is denoted by “node” in line 3. By default, builds are triggered by push events to any of the registered repositories’ branches as well as when pull requests are created; just what we need 😉

For much more options, check the documentation ( )

Build log in the TravisCI UI

Test coverage analysis with Coveralls

When executing npm test, coverage information is generated with gulp-istanbul. Although there are other possibilities on how this could be configured, we decided to use gulp-coverallsFollowing three lines are all we need to publish our test results to coveralls:

In the coveralls UI, we get a nice overview of how the coverage is evolving which each build and many more features.

GitHub Integration

All of the above is nicely integrated with GitHub, where we can directly see the build-state of our branches:

With a view more lines, we can add this information directly to our which gets displayed in the GitHub repository.

And what else could look more promising to any potential user of your open source library than these badges:


Last but not least: Big shoutout to TravisCI and Coveralls to stay at zero costs for open source projects!

Some useful links:

Github: generator-next
npm: generator-next


Leave a Reply