Testing CakePHP plugins with Travis CI

Making sure your freshly released CakePHP plugin still passes all of its tests can be a bit of a time sink. Setting up Jenkins for small project can be a big job. After I setup Jenkins once or twice, I personally longed for a simple way to get continuous integration with not much work.

Enter Travis CI

Travis CI is solves the above problem perfectly. Travis CI is a fantastic open source, distributed hosted continuous integration environment. Travis CI is a fantastic resource for the open source developer. Once setup, Travis CI will automatically run your test suite after each push to Github, and email you when tests fail. But, before you can use Travis CI you’ll need to add a .travis.yml file to the root of your project. This file tells Travis CI how to setup your project and run its tests. The documentation on Travis CI is quite extensive and covers many of the options I won’t be using in this example. After setting up the .travis.yml file, you need to register the Travis CI webhooks from your project’s Admin tab in Github.

For CakePHP plugins this usually means cloning CakePHP and setting up the database configuration file if your plugin needs it. Lets say you have a plugin called AssetCompress and it is in a repository called asset_compress. A basic .travis.yml file would look something like:

There are a few sections here, so lets go over them one at a time. The php section lets you define which version(s) of PHP you’d like to use. By defining multiple versions your tests will run against each version of PHP, and tests must pass in all versions for a build to ‘succeed’. The before_script section lets you run arbitrary shell commands before your tests or script run. In the above example we do a number of things in the before_script step:

• Clone CakePHP. This is done so we get an app directory and the framework.
• We move our directory, in this case asset_compress into one of the plugin paths.
• We update the permissions on the app/tmp directory, so there aren’t any file permission problems.
• A test database is created.
• The standard database.php is output into its place.

Now that all the setup is complete, the script block runs. This block should execute your tests, and in the example above it runs the cake TestShell. You can run any test case/suite you like here. I find it convenient to have a single test case that runs all the tests for a plugin. I always call this AllTests, as it is a simple convention to follow.

More advanced test matrices

I mentioned earlier that you can easily create testing matrices using Travis CI. As we saw earlier you can define multiple versions of PHP in the php section. In addition to multiple versions of PHP, you can set env properties. Values under env are set as environment variables, and used to create test matrices. For example if you had:

This will create a matrix of 4 builds. I use CAKE_VERSION to checkout different versions of CakePHP, to help ensure a plugin works with multiple versions of CakePHP + PHP. You can also use it to test against different databases if your plugin needs to work with different database platforms.
That’s pretty much all there is to it. After registering the webhooks you can view test results on Travis CI. One other nice benefit of using Travis is that any pull requests made to your project will also automatically get builds done. This makes it a snap to figure out if a pull request is going to break any existing tests.