I've finally come to grips with Test Driven Development (TDD).

For the longest time I was like, "Write a test for code I haven't even written yet? Sounds like wacky moon logic!" Which when you put it like that, does sound like wacky moon logic. However, this is clearly the wrong way to look at TDD.

Here's a real life example to help out. We'll assume you're writing a new piece of software and that you're also doing it in PHP. You might write a new Foo class with a method like setBar($bar) which will set a private member variable. Generally on whichever page you were developing this for, or even a sandbox page, you'd just do something like:

And then check the output to make sure that $F->_bar was actually set to 'asdf'. TDD you just formalize and capture this into a unit test. In PHPUnit a simple unit test for this would look like:

So now you've got a test that will make sure you've Foo::setBar() will always set bar correctly. If in a few months someone needs to update the Foo class to do something new, they can just re-run the FooTest unit test and know that they didn't break anything.

Rather than write throwaway tests while building code, I now write unit tests which will last for the duration of the project. The tests will also help document the code going forward. Never again will I need to worry about what a certain method is supposed to return.