Continuous integration is something I value a lot in software projects. If you are already hosting your code on GitHub, for public or private repositories, then you can leverage a lot of tools available in the ecosystem.

Travis-CI

Let me just quote their README:

Travis CI is a hosted continuous integration and deployment system. There are two versions of it, travis-ci.com for private repositories, and travis-ci.org for public repositories.

Once you enable Travis for your project, it will test all the branches for which it is enabled as well as the pull requests. Pure glittering awesome. Plus, if you look at their pricing, it is free for open source projects; … awesomeness squared. Head over to the docs, and get started.

Why?

Having some kind of metric to check that a commit is good or bad is useful. There is no point in doing an automatic merge of a commit that will cause tests to fail. Instead, it is smarter to apply changes locally, fix them and only then merge them.

E.g. GitHub shows Travis commit status:

That is a pretty neat integration with GitHub; when Travis tests your GitHub changes, it will then notify GitHub of your commit status (more info: commit status API).

Adding a badge to your README.md

Once your project is enabled, then you can also add the badge in your project’s README.md so it will show on the project page (or GitHub project pages). This will let your users (end-users or library consumers) know how everything is looking; and collaborators that they may want to spend some time fixing the branch.

E.g. xmlrunner build status:

Enabling Travis for your project

1. review the documentation.
2. go to the profile page.
3. profit.

Adding a .travis.yml configuration

1. review the documentation.
2. add a .travis.yml file.
3. profit.

Here is a minimalist configuration for testing a python project using tox, which I will cover in the next section.

Tox

Let me quote the tox doc:

tox aims to automate and standardize testing in Python. It is part of a larger vision of easing the packaging, testing and release process of Python software.

Two-liner example

Let’s start with a very simple example that involves letting setuptools run the testsuite (setuptools doc):

Testing multiple python versions

Let’s rewind for a bit… What is tox?.

Tox as is a generic virtualenv management and test command line tool you can use for:

• checking your package installs correctly with different Python versions and interpreters
• running your tests in each of the environments, configuring your test tool of choice
• acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing.

So would that mean I can test python 2.6, 2.7, and 3.3? Yes.