Archive for November, 2007

The word is that SimpleTest is moving towards PHP5 in the near future which is great news for all Mockists in PHP. When I moved to PHP, SimpleTest became the main ingredient in many a coding session up to 2 in the morning but once PHP5 gained traction and I was seduced into leaving PHP4 behind I found myself relying more heavily on PHPUnit. Not that SimpleTest is anti-PHP5 in any way (only some small things and obviously E_STRICT giving it a heart attack), but more projects I didn’t control leaned heavily towards PHPUnit once PHP5 took off.

Why the noting of SimpleTest? Because it’s a Mockist library. Between PHPUnit and SimpleTest, ST under Marcus Baker’s leadership stomps all over PHPUnit for Mock Object support, and has done for years. PHPUnit is a great Unit Testing library, but I just don’t like it when applying TDD (or even some limited BDD before recently). The SimpleTest documentation (which is itself deceptively simple) is basically a TDD tutorial which runs you through basic Unit Testing, how test-first approaches lead to better design decisions, and how Mocks and Stubs make designing even better by exploring the interactions between objects (i.e. SimpleTest’s introduction to TDD is behaviour driven) and server resources.

PHPUnit has always seemed to attract people who prefer to test state, or use Stubs predominantly (hand coded objects with fixed return values), or at a minimum those who can endure the lack of Mock Objects in their lives. I prefer none of these – being behaviour focused. I find it really hard to work with a Unit Testing library that first spent years ignoring Mock Object support, and which then bundles one which is a) a bit foggy, and b) rarely used or highlighted anywhere, and c) useful mainly on a hit or miss basis (some nagging missing features).

Is this short sightedness on my part? Maybe it’s just a matter of development styles? I am afterall relatively new to PHPUnit – SimpleTest has served all my needs previously since time began. What does the atypical PHPUnit user do though when they need a Mock Object or Stub? Hand code it???

I’ve become more interested in Mock Object frameworks recently, mainly to see the broad range available (count them for Java or Ruby and you get quite a collection) before dabbling in one for PHPSpec on the premise a loosely coupled Mock Object framework has value beyond PHPSpec (which I’m sure it does – phpt + mocks would be interesting, but other uses suggest themselves). PHPSpec + PHPMock = BDD At Last.

My vision is still pretty SimpleTest tinted. Noting this is only one part of PHPUnit I’m bashing, but the PHPUnit MO API leaves too much to be desired. It looks quite cute – PHP5, fluent interface, etc., all fluffy and friendly – but the fluent interface doesn’t flow naturally, and it seems fickle to a fault. Surely my syntax opinions are questionable, but I just like to have one that doesn’t need to be memorised so precisely and flows more intuitively. Handling of indexed method calls with parameters would also be nice – nearly everything I do with Mocks/Stubs needs it at some point. Dropping the fluent interface entirely might actually be an improvement until (if) it’s changed.

Is syntax really that important? I know Rubyists would have fun debating the benefits of Mocha vs Flexmock vs rspec mocks. Nearly the whole argument ends up being a syntax choice coloured by your approach to TDD or BDD. Some like to use real objects, others stubs, others mocks, and others even partial-objects that are more real than stubs but not production quality. Martin Fowler even has a wonderously clarifying post on Mock Objects and Stubs, and the kind of people who prefer each. Going by it, SimpleTesters who refuse to get with the popular program of PHPUnit (lots of them about still – many live over on Devnetwork) seem to more likely be inclined towards the BDD-related style of TDD – focusing on behaviour and object interactions over state and simple verification.

I mean here’s a quick thought. PHPUnit’s standard Mock Object example:

[geshi lang=php]$observer = $this->getMock(‘Observer’, array(‘update’));
$observer->expects($this->once())
->method(‘update’)
->with($this->equalTo(‘something’));[/geshi]
Seriously – this is just horrible! What about:

[geshi lang=php]$observer = $this->getStub(‘Observer’, array(‘update’));
$observer->shouldReceive(‘update’)->once()->with(‘something’);[/geshi]
Anyone see a difference? Obviously, with all my moaning above I prefer the second. It’s simpler, less typing, reads like plain English (I seem to note that a lot recently ), does the same thing, and just feels cleaner. I used Stub since it’s slightly more accurate for what this is doing – a canned response from an otherwise real object. SimpleTest refers to these as Partial Mocks; respects to Marcus but I still consider them Stubs with partial Mock behaviour – just to be vague, difficult and convoluted .

Personally though, this is all enough to convince me SimpleTest remains the Mockist’s hero. PHPUnit is all shiny and bespeckled, but it’s just not working for me since I rely heavily on Mock Objects and really really don’t like writing Stubs (except for server/slow resources) if I can help it.