Unit testing will save you time, money and hair
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:
Show Plain TextI 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.
These slides were used in a 2 part talk given at CakeFest Argentina on unit testing in CakePHP
If you’ve ever tried to subclass a PHP4 static class you may have come to same conclusion that I have its a total pain in the neck. However, I think I’ve come up with a not too terrible approach.
With all the talk of testing going on, I thought it would be good to look at how tests work and what is makes them tick. SimpleTest handles the bulk of test case execution, however, there are a few CakePHP specifics that are not part of a normal SimpleTest::UnitTestCase.
Super fresh in the SVN builds of CakePHP 1.2 is the new code coverage analysis. If you are living on the bleeding edge of cake development or just want a preview of the neat things to come once 1.2 is complete read on.
The guys at debuggable have contributed a fantastic tool to the testing suite for CakePHP 1.2.