How We Test Drupal 7 Modules on Travis CI

If you've been working much in open source software recently - especially PHP - there's little doubt that you have likely heard of Travis CI. For those don't know about Travis CI, it's a free hosted continuous integration solution for public open source projects (they do have a paid version for private projects, too). Travis CI is a great tool for running your automated tests on each commit and pull request for your project's Github repository.

At VM(doh), we believe that if it's not tested it's broken. We use Travis CI for testing the libraries and Drupal modules that we build. In the past, we've used our own Jenkins server for that task, but we decided that moving to Travis CI meant one less thing to maintain.

Why don't we just use Drupal.org's testing infrastructure? Simply put, the infrastructure that we need is not in place there. We tend to deal with third-party applications, and testing things like integration with Elasticsearch or cloud queues just isn't possible on Drupal.org.

Running tests for Drupal 7 modules is easy on Travis CI. You just have to be willing to do a little work in the .travis.yml file so that Drupal's Simpletest tests will run. Yes, Drupal 7 uses Simpletest instead of PHPUnit, and thankfully Drupal 8 will be getting more sane and using PHPUnit.

Below is the current (as of today, at least) .travis.yml file for the Search API Elasticsearch module.

That might look a little overwhelming at first, but it's really rather simple especially for what it does. For this module, we're actually running six test builds. We support both the Libraries API and Composer Manager for using the Elastica dependency, plus we test on 5.3 (Drupal 7 minimum), 5.4 (widely deployed), and 5.5 (failures allowed, but we do want to see if we need to make changes for compatibility).

Before installing Drupal, we install Drush to make our lives easier. These days, installing Drush from it's PEAR repository installs a 6.x version by default, and that's great because "drush test-run" now only uses an exit status of "0" on success. In the past, you had to grep the test results to check for errors and then manually return an exit status of "1" to mark a failure. (Drupal's run-tests.sh script also returns an exit status of "0" whether or not it succeeds.) By the way, we also use a shell script to configure and install multiple instances of Elasticsearch for testing.

There is a very important PHP configuration change that you'll want to make before actually installing Drupal. When you install Drupal, it tries to send an email to the admin email. To trick Drupal, we tell PHP to use /bin/true as the sendmail_path on line 43.

The rest of the script is essentially going through the steps you'd use for a Drupal installation and using Drush to run the tests. We run the tests in debug mode so that we can see what Drush was doing every step of the way.

The last section you'll notice is the notifications. Travis CI allows you to send notifications of build failures and fixes to many destinations. We typically send public notifications to our public IRC channel.

Now what about external APIs where you need credentials? Travis CI supports this, too. Let's look at the .travis.yml file for Marconi:

For the most part, the .travis.yml file is the same as the one for Search API Elasticsearch. However, there are a few things you need to do to get tests to run when using a third-party API.

In the Marconi module, we call environment variables for credentials during testing. Travis CI presents two easy to overcome problems for this situation. The first is how to include API credentials without exposing API credentials. Fortunately, Travis CI has a way to encrypt your environment variables, and we do that on lines 10-13 to setup the API credentials we need for testing.

The second problem is telling PHP to use environment variables. The default configuration for variables on Travis CI is "GPCS" which means that Travis CI won't use environment variables. That's why we change the variables_order setting to "EGPCS" on line 33.

Obviously, if you don't need to install or use a thid-party application, you can skip those parts of running an extra build script or setting secure environment variables, but the rest remains the same.

If you liked this post, you should share it...

Comments

Lars Olesen (not verified)

May 9, 2014 - 3:21pm

Doesn't the make file interfere with other makefiles including your module?