Archive for January 5, 2006

Cerebral Cortex; Over to Zend

I suppose that the migration was inevitable (well, it can’t all be bad!). Davey Shafik, author of perhaps the only PHP Framework I genuinely enjoyed using has decided to end his work on Cerebral Cortex. Shortly after the end, he was quickly hunted down and drafted into the Zend Framework project – here’s hoping he can bring that ever elusive simplicity to Zend! :-) You can read Davey’s blog over on Pixellated Dreams – http://pixelated-dreams.com/.

Back Online; TDD and PHP Testing

And hey presto – the blog is back…;-) Yes, after over a month of waiting I finally got around to reinstating the blog… About time say we all. Onwards…

On topic – if I can for once. One of my many practices as a developer/auditor is keeping up with the latest practices (obvious really). One area I’ve been interested in since running into XP is Unit Testing, in particular TDD (Test Driven Development) a practice whereby developers write code which conforms to pre-written test cases.

Testing (far as I’ve seen in PHP) is generally not done with an existing tool in such a way as to be reperformable (i.e. any developer can reperform the exact same test with the exact same data). Mostly developers rely on debuggers, error reporting, and the miracle of echo() and var_dump() to dynamically test and debug. Nothing with this incidentally – its just that on-the-spot tests cannot be reperformed quickly.

For myself, I’ve been cultivating a relationship with SimpleTest and PHPUnit (unit test libraries) over the past few months. Basically I either plunged in head first or stayed at the shallow end. My conclusions are that TDD are immensely useful – but also immensely tedious and time consuming. My usual 40-40-20 rule is more a 20-30-50 rule while coding Quantum Star SE and Partholan.

I have lots of gripes about TDD. Its tedious, painfully time-consuming, not always intuitive, limited when you’re forced into creating Mock Objects, and you have to maintain tests in line with developed code. Gripes, but not fatal ones. TDD does force you into designing more open independent OOP, promotes a high quality, reduces future maintenance, and allows detailed documentation of application behaviour (I agree with the concept that few people actually read documentation – so I phpDoc and leave it there).

Overall TDD is worth the effort. I surprised myself with QS; I’m not a full-time developer being more inclined to audit than write applications but using TDD made using Design Patterns more relevant and intuitive. I have indeed caught the TDD bug I fear… My experience so far has been that the massive (and its painfull) upfront investment saves time later on. Something you’ll never see until you work on a single application over a few months; long enough to see benefits.

More recently I’ve been following a few new developments in PHP testing. Those following Chris Shiflett’s Blog and the PHP UnitTesting movement will have become aware of a movement towards integration with Apache-Test, or rather making PHP’s unit testing libraries (PHPUnit and SimpleTest) produce TAP compliant output for Apache-Test. Chris is involved in the charge, and mentions it on a recent blog entry (http://shiflett.org/archive/176). This (IMO) is a nice step. Perl has been way ahead of PHP with the Test modules for testing, a dog simple test method that has a lower entry point than PHPUnit or the similar SimpleTest. Nevertheless with both these popular libraries now supporting TAP output use of the Apache-Test framework as a basis for testing is widely available – probably even for pre-existing test suites. Nicer even is the update to the SimpleTest TAP reporter (ve have declarations mein fuhrer!) so you can set TODO/SKIP or just bail out of the tests altogether.

Of course this all brings home why I like Perl testing far more than PHP testing. It may be time to look into the PHP Test::More conversion which Chris mentions and compare it against my current use of SimpleTest. What’s nice about Test::More is that its functional testing (typically) so it can be used with procedural code whereas SimpleTest is largely restricted (with TDD largely) to OOP. Balancing Unit and Functional tests might be a little less time consuming, and provide a little better catch mechanism for bugs…