Unit testing will save you time, money and hair
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.
At work we’ve been using selenium webdriver to enable automated browser testing as part of our regression suite. One of the most difficult parts we’ve had is maintaining DOM synchronization.
In the last article I went over the various static analysis tools I’ve found useful, and how to get them installed. For this installment, I’ll be going over how to use make to run all the tasks, and how to configure all the tools to work with Jenkins.
I’ve recently integrated static analysis tools into both my day job’s and CakePHP’s development process. Setting up static analysis tools is reasonably easy and can help you find problems before you even get to unit tests, or staging sites. They are also the ideal tool to help enforce coding standards, and best practices that can be checked by reading the code.
We use selenium extensively at work for automated acceptance tests. If you’ve never used selenium, it allows you to record and playback browser sessions and create integration tests from the perspective of a browser. Its generally a great tool, and really helps make sure we don’t release broken code. Recently, however I’ve found Selenium can have adverse reactions with jQuery.
With the recent release of PHP 5.4-RC1, I wanted to give it a spin and make sure there weren’t any upcoming issues for CakePHP. I recently saw a great article from Derick Rethans on getting PHP setup from an SVN checkout.
I recently had a fun idea, that I wanted to try and implement for PHPUnit. I really like coloured console output. PHPUnit already has the option for coloured output, but I wanted more. I wanted to get coloured text for F, E, S, and I that showed up in the test run progress.
Previously I wrote about the changes that have been done for the request handling in CakePHP 2.0. Response handling is another subsystem that has received a significant facelift. As with request information and functionality, response related features were spread across several objects. Controller, RequestHandler and Dispatcher all had a slice of the pie.
A talk given at CakeFest 2010 about unit testing, mock objects and continuous integration.
As you may or may not know CakePHP is transitioning to PHPUnit and with this transition comes a totally new Mock object interface/implementation.
In the recent bakery article concerning the ongoing development of CakePHP 2.0. The already underway migration from SimpleTest to PHPUnit was introduced. I wanted to go into some of the reasons and motivations for that decision as well as explain some of the long term benefits.
Shells are one of the more difficult objects to properly unit test. Since they normally run in a CLI context instead of a web context they provide some interesting challenges. The biggest hurdles are separating the Shell from the CLI environment, and simulating the correct arguments and parameters.
So originally when I built this site, I was in the “requestAction is bad” camp. So much so that I created a convoluted Component to assist in the creation of the sideboxes featured on this site. A sample of that code is as follows:
//Recent Posts
$options = array(
'position' => 5,
'type' => 'list',
'format' => array(
'title' => '{n}.Node. I spend a lot of time in various IRC channels answering questions and helping out, and one recurring theme that pops up again and again is people not knowing what to do when things go wrong. Whether it be a simple error or a logical mixup, people often lack the tools or processes to figure things out. So I thought I would share how I approach errors and problems.
In the ongoing struggle against code bloat and creative ways to do things, I’ve been playing with throwing exceptions from model methods. While not earth shattering stuff, I’ve found it to have a few advantages over returning false. First, you can end up with less if and else statements.
Re-factoring code is a part of any programmers life or should be. Very few people write beautifully clean and well factored code from the start, and I am certainly not one of them. Most times my code starts out a sprawling tangle that takes an additional pass or two to look like something I would consider clean. I find that when programming and designing I start with a rough idea or sketch of what I want to accomplish.
As most people know TextMate is a pretty amazing text editor, probably one of the best for MacOS. What you may not know is that CakePHP has its own textmate bundle. this bundle is maintained by Joël Perras who is also a recent addition to the CakePHP core team.
I recently wrote an article about testing CakePHP controllers the hard way where I covered testing controllers by running their methods manually. I hinted at some additional tricks that could be performed by using Mock Objects. Today I’m going to spill the beans on Mocks, and how I use them when testing my Controllers.
By now you already know or should know about CakeTestCase::testAction() and the wondrous things it can do. However, testAction has a few shortcomings. It can’t handle redirects, it doesn’t let you use the power of Mocks, and its impossible to make assertions on object state changes. Sometimes you need to do things the hard way, stick your fingers in the mud and work it out.