gsocneurostarsbiostarcontinuous integrationtestingtravis-ci

Testing NeuroStars w/ Travis-CI

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. […] The main aim of CI is to prevent integration problems, referred to as “integration hell” […].

CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests in the developer’s local environment and verifying they all passed before committing to the mainline. This helps avoid one developer’s work in progress breaking another developer’s copy. If necessary, partially complete features can be disabled before committing using feature toggles.

Later elaborations of the concept introduced build servers, which automatically run the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP

Automated testing is a good practice in software engineering, wise men say. In NeuroStars we make use of the integrated Django testing tools to run our unit and integration tests.

During my GSoC2014 we would like to take this one step forward, using a build server to perform automated testing. I already had some experience with Jenkins CI, but in this case, Roman and I decided to try Travis CI.

The main advantage of Travis CI, when compared to Jenkins CI, is that small Open Source projects like NeuroStars can make use of the free Travis Continuous Integration Platform and avoid the burden of managing an actual build server.

Configuring Travis CI for a project hosted at GitHub is really easy: it’s about adding a few lines to a YAML file. I also configured GitHub Webhooks in my repository, so that on every git push GitHub sends a notification to Travis CI and a testing session is triggered in order to test the new code.

Now my workflow is the following:

  • write new code;
  • test it locally, skip the slowest tests;
  • commit and push the code;
  • receive an email from Travis CI with the results of the complete test session.

I must admit that I am very satisfied with this procedure as it gives me more confidence about the code I write daily.