Warning: This entry uses the word “Ruby” in a context that explains how in “one aspect” it’s “better than PHP”. Try not to cry…;). If you can’t live with Ruby having a few tools PHP doesn’t quite have yet, you shouldn’t read any further.

To throw out a few keywords so some cross-language developers can sagely nod their heads: Autotest, Mutation Testing, Mocha, Rspec, Heckle…what’s that other one? Hpricot.

Anyways, here’s the pitch. I’ve been using Ruby for a year now and my pet peeves with PHP started getting a bit too much to comfortably endure. Luckily, for all my PHP readers who think I’m brilliant (or at least good enough to fake it ;) Shhh…), I don’t like developing web applications with Ruby, or that thing Rails. Whatever it is. It’s a framework, right? So I’m on a splurge of writing PHP tools for the same things in cahoots with folk like Travis Swicegood (edit: as far as I know Travis is totally innocent of being a Ruby-Lover – I’m the one you want to flame for being “rubyesque” or whatever ;) ).

But Ruby has a few non language-specific testing ideas I love to bits. Behaviour-Driven Development is one of them (sorting that out with PHPSpec, and PHPT is showing some lighter weight advances which are worth noting). Another is ZenTest’s Autotest.

Autotest rocks. Yabba dabba doo style.

If there was ever something I’d use Sara Goleman’s introduction to the mystical art of PHP Extension writing for (great book), it’s to interface to every notification daemon/app I have running on my OS’s. You see, using any testing framework I open my IDE, edit some classes and their respective tests, flip to the command line, re-run my tests, wait a while, and get a result. It’s all nice – and it sinks time once the tests reach the level of needing anything beyond a split second to run.

How much nicer then to have a tool checking all my project files for modifications, running only the subset of tests effected, and reporting results via a popup notice with green/red feedback colours – all in a second or two? What? No “phpspec -r” or “pear run-tests -rq”? No running all tests, or selecting a specific group/directory? Absolutely not. I don’t even leave the IDE window… It’s autotest afterall – human interaction not required.

Then there’s Ruby’s Heckle for Mutation Testing. Actually PHPUnit has something on this already (there’s another Sara Goleman link to PECL’s runkit which it uses). Not in the release branch yet, but hopefully it’ll get in there at some point. For PHPSpec specifically I was thinking about planning mutation testing for a few months time, but couldn’t really think of a good solution. PHPUnit’s wiki has some posts from the Mutation Testing author (part of the Google Summer of Code) and some of the dependencies from PECL seem to carry some small problems making it more difficult than it should be.

I noted earlier today it may pay to remember PHP runs from the command line – so you can use multiple processes, and access multiple copies of class definitions. You could feasibly create 100 classes called Logger, mutate them on the fly on a per process basis, and throw them at tests all day long. You’d only need 100 sequential PHP processes (one per mutation – nothing odd there for a PHPT user) tied together to a Heckle-like PHP clone. The only concern would be using it only on code which is clever enough not to redeclare existing classes. Sounds like a simpler route compared to using PECL runkit et al. in the one process.

Just to finish up there’s Ruby’s Hpricot. Hpricot is plain annoying, though PHP isn’t too far behind it. For many things DomDocument just works great. Hpricot however just feels better – how can you resist using a lean API like:

[geshi lang=ruby]doc = Hpricot(“That’s my spoon, Tyler.”)
doc.at(“b”).swap(“fork“)
doc.to_html
# => “That’s my fork, Tyler.”[/geshi]
As an HTML parser and general toolkit it’s addictive. It even parses XML :( . You could probably just write a clone right on top of DomDocument and who’d care?

Related posts:

  1. Any Behaviour-Driven Development Tools for PHP?
  2. PHPSpec hits Subversion Revision 100
  3. PHPMock: Independent Mock Object/Stub Framework
  4. Thoughts on a Unit Testing and Test-Driven Design Experience
  5. Mocks, Stubs, And SimpleTest Wins