Archive for April, 2013

Interesting (CakePHP/PHP) links – 2013

16 Apr


Try/Catch/Finally is a nice article about upcoming 5.5 features – and how to use them wisely.

Enhance your select form fields

Chosen is a beautiful addon for your select dropdowns, especially if you use them to filter to search on a large set of data and if you do not yet use any AJAX here. Just add some markup and JS and you got a quick and easy way to handle them.

There are also some CakePHP Plugins for the Chosen script available already.

SQL to Cake find statements

You can use this converter to form your SQL snippets into Cake find() calls. This is especially handy for beginners, but can also be useful to automate some migration scripts etc.


Continuous integration with Travis and CakePHP

03 Apr

I must admit that I only recently started to take testing more serious.
In the past I just created tests if too much time was available.

But the larger projects get, the more just minor changes will most likely break other pieces in them, as well.
Most of the time you don’t even realize it until it is too late, and people report it broken after deployment.
To avoid this, it is wise to have a good test coverage of your project.
Also, it helps to have some software that tests your projects continuously and automatically. This is where Jenkins or Travis come into play.

In the following tutorial I want to focus on how use the free Travis CI to automatically test your github repositories automatically after every commit.
Jenkins you would have to manually set up on your server. Travis is already available with only some minor configuration (for free repos anyway).

Note: For Jenkins there is some documentation in the cookbook.

Travis Setup

You need to get a Travis account first. The easierst way would be to sign in with your github account as this automatically sets everything up. Then you just need to enable the github repositories you want to be tested.

Github Setup

On github you also need to enable the corresponding "Travis hook" for your repositories. It will also need the token you can get from the travis settings page.

Then we need to make our ".travis.yml" configuration file. The documentation is pretty good, but I will still outline the major pitfalls.
A basic version to test your "YourPluginRepository" plugin code for PHP5.3 and PHP5.4 would be sth. like this:

language: php
  - 5.3
  - 5.4
  - git clone --depth 1 git:// ../cakephp && cd ../cakephp
  - mv ../YourPluginRepository plugins/YourPlugin
  - sh -c "mysql -e 'CREATE DATABASE cakephp_test;'"
  - chmod -R 777 ../cakephp/app/tmp
  - echo "<?php
    public \$test = array(
      'datasource' => 'Database/Mysql',
      'database' => 'cakephp_test',
      'host' => '',
      'login' => 'travis',
      'persistent' => false,
    }" > ../cakephp/app/Config/database.php
  - ./lib/Cake/Console/cake test PluginName AllTests --stderr
  email: false

Save this file to your repository root.
After the commit and push Travis should be notified via hook and your first test build should already be in the queue there.

If you want to take a look at some more complex travis setups, take a look at my tools plugin or the cakephp repository. Both also use different CakePHP versions or database types.


If you take a look at the Build-Lifecycle you can see that you have the possibility to install additional software/packages and configure your build to your liking prior to executing the tests.

Status image for your readme or website:[YOUR_GITHUB_USERNAME]/[YOUR_PROJECT_NAME].png

Current status for my tools plugin

That was actually the main reason I started to try out Travis. The plugin got larger and more and more apps started to use it. I had to start thinking about how to make it more stable and reliable, especially after modifying parts of it. Regression tests really help here a lot!

Just as an example image:
Build Status

I noticed, however, that this image does not change very often. So if your build does not pass anymore, don’t rely on this image. Better use the notification hooks to get alerted 🙂

Sugar: Coverage via Coveralls

You can include coverage results and also get a detailed report for each class.
It is easiest to use the travis plugin then, as the coveralls setup is quite complicated otherwise.
See my Tools plugin on how to get it working.

You can show a neat little batch in your readme as well:


It seems I wasn’t the only one writing something about this. Independently, Mark Story wrote an alternative article about the the same topic.