Test Driven Development

I have been reading a lot lately about software development processes. One of the most fascinating ideologies I have come across is Test Driven Development (TDD). The theory, as I understand it, is that you start the process by writing a test case. At this point you have no code so your test fails. Now you create enough code for your application to run. You then run your automated test against your application and it will fail - remember that you only wrote enough code to get your application running. Enough code is then written for the test to complete successfully and then you move on to the next test case, refactoring at the beginning of each successive iteration.

What most appealed to me, initially, is the fact that you are writing unit tests from square one. That's absolutely wonderful. Unfortunately many developers in the real world (I am guilty of this one) wait until the last minute to write/perform testing on an application. I won't go into why this is bad, just know that it is. TDD forces you to write your tests up front, giving you the ability to run your tests with every build. This also allows you to perform regression testing - BRILLIANT! Why haven't I come across this before? The more I research the more I learn.

Proponents of TDD also boast that writing unit tests up front leads to improved application design. Boy are they right! In writing tests you are interfacing with your application before it is even constructed. If your tests don't make sense, then your application won't make sense. This is a good indication that the design needs to be revisited. I love it!

Some helpful links...
http://www.nunit.org/
http://www.testdriven.com
http://codebetter.com/blogs/jeremy.miller/