PHP in Action

Again a somewhat belated announcement: PHP in Action is in print. My copies of it arrived at my doorstep while I was in Crete, with no clear indication that would have allowed my brother, who was hovering helpfully in the vicinity, to guess what it was. I guessed it, though.

But DHL couldn't give any definite answers, and their Norwegian branch have a menu on they're telephone answering machine that gives a whole new dimension to the concept of a poor user interface. My colleague had a worse time, though. He was the victim of identity theft. His shipment of Java books, also delivered by DHL, was hijacked by someone who forged his signature.

Oh, my dear, I've just had a book published, and here I am chatting about everything else. Strenuously objective as always, I have to say that it's a pretty good book.

I've had to read it about fifteen times already, and I still sort of enjoyed it the last time.

In a blog post by Paul M. Jones, he quotes comments from slashdot claiming that TDD leads to "ravioli code":

The problem is that it [Ravioli Code] tends to lead to functions (methods, etc.) without true coherence, and it often leaves the code to implement even something fairly simple scattered over a very large number of functions.

The problem here is the phrase "tends to". Any reasonable comparison of test-first with test-later has to be between code examples written by the same programmer using the two approaches. Those who write messy code might well continue to do so even with TDD, but in a slightly different way. Even though I do believe TDD helps, it's not "the cure for all diseases".

There is another point which these commenters have missed: when you write the tests first, they are useful to you right from the start. Test-later means something like: write code for a while, then run an ad-hoc test. At that point, you've probably created two or more bugs, and you have to spend time figuring out which is which and where they're located. After you've fixed the bugs, you write some more code, and then you run another ad-hoc test, perhaps re-implementing the code you needed to do the first ad-hoc test. With TDD, you can run tests over and over; you get immediate feedback about bugs and you can fix them quickly

The diagram, which I used in the book, illustrates my point. First, there is TDD, using the tests from the start, then test-later development.

I created my own test runner to run tests inside Vim, I can't remember how long ago. Must be a year or two. I never shared it with the world. It was too primitive for anyone else to use. Then, recently, I decided to try re-implementing it in a more serious way. That meant using a more sophisticated programming language. Vim script has seen some improvements and is pretty useful for simple tasks, but I want something that's object-oriented and has a test framework. That means Perl, Python or Ruby, all of which are available from inside Vim. So I've started doing it in Ruby.

It's not ready for public consumption yet, but I think it will be eventually. Here's what it looks like at the moment:

This is how I program about 90 per cent of the time: the test case and the class I'm testing side by side and a small extra window to show the test results. I can run the test by pressing F11 (which just happened to be the key that was available at the time). I work test-first, so before implementing something on the left, I have to write another test on the right. It's less tempting to start implementing without tests when there's an easy way to run the tests.

• Main
• Archives

• How code comments deteriorate
• How harmful is "harmful"?
• Comments considered harmful
• The one-line web framework
• How to test everything
• Zend_Test
• More beautiful code
• Beautiful code
• Refactoring is design
• Get links with XPath

• Application design [19]
• PHP [28]
• Refactoring [3]
• Frameworks [4]
• Testing [13]
• Ruby [3]
• Smidig2008 [1]
• Java [1]
• General [0]
• CSS [0]
• JavaScript/Ajax [0]
• Me [4]
• Vim [1]
• Humor [0]

• RSS 0.90
• RSS 1.0
• RSS 2.0
• Atom