Introduction

In my development career there have been many instances where I had just discovered a new technique and straight away realized on how much I’ve been missing out. Test Driven Development is one of such technique which I adopted couple of years ago and very much regretted not adopting it any sooner. From then on I followed TDD style of development on all the major projects that I worked on, except the ones which were of temporary nature and with super super tight deadlines

What is Test Driven Development?

In a traditional or should I dare say the old school way - testing was followed after the development phase. The testing team would perform set of Unit test, Integration Tests and various other tests only after the coding was completed.

Test Driven Development emphasises in doing exactly the opposite, stressing the need of writing test cases before writing the code itself. Now I know it seems all a bit strange to start with. How can one write test cases for something which doesn’t exist yet??? But that’s the entire point - it enforces the developer to be very clear about what tests the program should pass and what test it should fail; therefore, bringing such concerns to the forefront of the software design process.

It may sound weird, but I’ve written many class libraries and sometimes the entire project without having to run a debugger, while using the Test Driven Development method.

Steps in Test Driven Development

So on a very broad level here is the sequence for TDD.

1. Write a test: Each new feature or more specifically before implementing each new method in a class, write a test case for that particular method first. Yes, you’ve read it right, the class and the method doesn’t exist yet, but we are writing a test case for it.
2. Run the test: Obviously as the class/method that is being tested doesn’t exist, the test project won’t compile and you will get an error. So create the class and the corresponding method, but don’t implement the method yet, instead throw an Exception in that method. Run the test and expect it to fail, this validates that the test case fails, when the method that is to be tested is not implemented as per the test case expectations.
3. Write some code: Write code for the corresponding method with the goal of passing the test that failed in step 2. The code doesn’t necessarily have to be elegant but should do the job that it is supposed to do. 
4. Run the test: Run the same test again and see it passing.
5. Refactor the code: Update/refactor the code written in step 3. The goal here is transform the inelegant code written in step 3 to elegant code. After refactoring run the test and see it pass.

 Repeat the above steps for each new feature that is added in the code.

In my next blog in this series, I’ll demonstrate the above steps using Visual Studio and NUnit testing framework.