debuggable

Following up on yesterday's part 1 of this introduction we have to deal with the question why someone like you or me should use Test-driven Development. Why should someone take on very small steps in programming?

Why should we use Test-driven Development?

Test-driven Development is about managing fear in programming. We have all been in a situation where we had to tackle a complex programming problem where we couldn't see the end from the beginning. We are afraid of not getting the system to work - at least not without a long bugtrail. Fear in general, and particularly in programming, has a host of other effects, too:

• Fear makes you tentative.
• Fear makes you want to communicate less.
• Fear makes you shy away from feedback.
• Fear makes you grumpy.
• Fear makes you inferior.
• Fear gets you out of control.

None of these effects want to be experienced - especially not in programming. When you are tackling one of these very hard programming problems, these effects of fear can be the reason for the project to fail. They can be the reason for you to fail. Test-driven Development is about eliminating fear when programming.

How should we tackle a difficult programming situation?

• Instead of being tentative, begin learning concretely as fast as possible.
• Instead of hiding in your pit, get out and communicate more clearly.
• Instead of avoiding feedback, go out and ask people for feedback.
• Instead of getting inferior and out of control, work on being superior all the time.
• Avoid getting grumpy - life's too short to waste your energy. :)

Programming is like facing all other sorts of tasks. When you break a big task up into small chunks you cannot only measure your progress, but you can also better organize yourself and get the task done. The tests in Test-driven Development are like subtasks of the one big task - the project. Once we get one test working, we got it working forever. If it fails, we can quickly fix it up. The important thing to note is that we have someone (our tests) notifying us about crashes in our application.

With another test working we are one step closer to getting the overall system to work. When one test fails, we didn't go one step back. We went forward another one, because our code taught us a lesson about itself - about its relation to other code, input, etc.

Should we always use Test-driven Development?

I am a firm believer in Test-driven Development. However, some people like Kent Beck - author of Test-driven development by Example, say that it's also good enough to revert to your ordinary programming practices as long as you reserve TDD for special occasions. However, there are occasions where TDD is still insufficient.

Think of PHP security. Of course you can test whether your security barriers work. However, you cannot test whether your security methods are efficient enough to make hacking the system impossible.

Getting setup with Test-driven Development

There are numerous frameworks for using Test-driven Development with PHP. The two most popular ones are PEAR's PHPUnit and SimpleTest. I very much prefer the latter, because it has an easy-to-use Eclipse plugin, my preffered IDE / Editor. However, SimpleTest is not limited to Eclipse. You can of course use the framework with any IDE or set up, simply by including the appropriate SimpleTest files within your code.

I would like you to download SimpleTest follow the installation instructions in the readme. Then you can play around with it already and tomorrow we will really delve into the topic of Test-Driven Development. :)