Recent Posts


Everyone is a Test Driven Developer


Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Updated for Magento 2! No Frills Magento Layout is the only Magento front end book you'll ever need. Get your copy today!

There’s surprising number of programmers who scoff at the idea of test driven development, probably because it’s packaged up with other, less valuable ideas and concepts, (lack of discipline masquerading as Agile, for one).

Here’s the thing though, everyone is a test driven developer.

Let’s take a simple programming problem; Write a function that takes two integers as input and returns their sum. So, you write your function.

function sum($a, $b){
    return $a + $b;

Easy as pie right? What usually comes next? Do you throw your code into production immediately?

Well, no. If you’re like most programmers, you throw together a quick program to test the output

$foo = sum(40, 2);
echo $foo;

The number “42” gets output to your screen. Satisfied your function works, you move on to the next thing you have to do.

Boom, you just ran a test. All Test Driven Development does is formalize this process. You write some code to run the manual testing described above, and you keep the test around to make sure things don’t break your function later on.

That last part is important. Let’s take our pretend example a step further. A manager comes to you and says

Manager: OMG, sometimes we’re printing 666 to the screen

Programmer: Um, so?

Manager: We can’t have our investors thinking we’re the anti-christ! Fix it!

Programmer: What?

Manager: The baptists! We sell software to the baptists! FIX IT!

So, grumbling, you add a bit of exception handling

function sum($a,$b){
    //sum the numbers.  You know, since almost every programming
    //language has a built in addition operator, this is a really
    //lame example function
    $sum = $a + $b;

    if ( 0 == ($sum % 666) ){
        Throw new Exception("Major Error: Either Daniel Wormword or my Manager is a wanker.  One is a fictional character, the other signs my performance review.");
        return $sum;

You then add a test case that looks something like this

//if sum returns 666, throw an exception
//wanker manager. wanker baptists
public function testSonOfSatan(){
    $test = FALSE;
    } catch (Exception $e){


Fast forward a few years when both you, and the manager, are gone (but the baptists still run the show). Some programmer removes the $sum % 666 business to fix a bug, not realizing it was a key project requirement.

Boom, test case fails, forcing future programmer to face the problem rather than let baptist angering code into production.

Having the computer test your code also lets you, the programmer, be a little bit lazier. You no longer have to keep referring back to the spec or keeping the niggling little details of the program in your head while you’re writing code. If you write your tests first, all the assumptions get captured there and you have one less thing to keep in your head while you’re programming.

Unit Testing, TDD, and the like are process tools. Like any process, you can go overboard. One hundred percent coverage probably isn’t necessary, but to completely eschew the entire concept is both foolish and shortsighted.

Originally published November 17, 2007

Copyright © Alan Storm 1975 – 2023 All Rights Reserved

Originally Posted: 17th November 2007