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.
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.