What is so different in Test Driven Development(TDD)? Its a methodology which seems to work in reverse. That is – you write the test code, write the actual code and refactor. So, what is the advantage? We are so used to – write the code first and then write the code to test it – that this seems a bit counter intutive. But, if you think about it, it makes sense, a lot of sense. Why? Once we write the code we know what we have written and generally we tend to write to tests that seem to test what we know will work! If you reverse the method, you can think about what are the different ways the user can use your functions. This has the following benefits:
- Your functions( or APIs ) will be better since you are trying to find out how the user will use your code even before you have written your code!
- The code seems to be more robust since you are anticipating before hand what are the different ways your code can go wrong!
- It makes your code design and code better
- The test-code-refactor cycle eventually leads to better design and robust code
If you try to decipher how the user will use your code after you have written it, you will realize that the APIs you are providing are cumbersome and non-intutive. TDD will make your APIs more usable, easy to use and robust. Since you are the first user of your to be written code, you can fix some of the issue even before they occur! Why refactor is needed. Refactoring is needed since we all recognize that – doing things right the first time – works only in theory! We usually discover better way of doing things once we realize the limitations of current implementation. These limitations are called ’smells’ in the agile world. Refactoring tends to make the code more robust and easy to maintain and leads to lower life cycle costs over years.
You can use NUnit, JUnit or CPPUnit for writing your test cases before you write the test code. You can use refactoring features available in the Visual Studio or in Eclipse for carrying out the refactoring.
