Christos Tranoris

You are a top object-oriented developer. You have written many algorithms. Have you ever wondered for the quality of your code?

Well, Test Driven Development (TDD), is an evolutionary practice for development where you write a test before you write production code. In other words, it’s one way to think the requirements through your design before you write your functional code

The next diagram shows how your programming practice flows: 

The first step is to quickly add a test, enough code to fail.  Next you run all of your tests, to ensure that the new test does in fact fail.  You create some production code to make it pass the new test.  Run all of your your tests again.  If they fail you need to edit/refactor your production code and run again all of your tests.  Once the tests pass the next step is to start over with a new test.

Occasionally, run a code coverage utility and check if your tests cover all your statements and brunches of your production code. If not then add a few more tests and maybe some production code.

What I really like with the TDD practice is that you actually don't need to write so much documentation of your code, since all the interfaces and use cases that you realize with your production code, are all included.

If you visit/refactor your code after a year, you fix something and you can see at a glance if something is broken before you release that patch.

Plus, have in mind that only you, the developer, knows better your code. Don't leave it only to the QA guys. They only see your code as a black box and they only limit themselves to QA Acceptance testing. You on the other hand can cover all the tests..even hidden paths that nobody knows!

Developers often say we can’t spend time now to also program tests, we make testing after the code is done, that’s what we have a QA group, It’s really simple code, it doesn’t need to be tested...

Well that are all the excuses you can say. But still, try to sit back, grab a nice TDD framework for your lovely language, and start following this practice. I believe that when you will need to deploy that patch with zillion features that your project manager needs to deploy yesterday you will realize the value of TDD by giving quality code and as bug-free possible as promised.

Probe further:

Read  Kent Beck's book , who popularized TDD in eXtreme Programming (XP) 

See this very nice introductory article from Scott Ambler, which has also links to many language tools 

see more info on wikipedia