Making the Move to Test Driven Development

Posted by Kirby Turner on June 8, 2004

I have been using NUnit since its early days but it has only been in the last six months that I have made the move to test driven development. TDD is concept of writing production code based on unit test cases that are written first. And using a framework such as NUnit enables the developer to write automated unit tests that will test the features of an application at a functional level thus encouraging test driven development.

TDD is a paradigm switch for many developers as it was for me. Sure I have been unit testing my code for years. I would employ techniques such as console applications, shell programs, and other types of test harnesses to test the functions of my code. But until recently I never
started the development of a module by writing unit tests first.

Test driven development is an investment up front in the quality of your code. That investment is in the form of the unit tests before production code. Many developers today write the production code first (after the design phase of course), followed by commenting the code, then followed by testing the code. And in many cases the later work of commenting and testing never happens because bug fixes become the developer’s top priority. But by investing in the quality of the code at the start developers will find that bugs are reduced, the classes and functions of the code are better designed, and over all quality of the work is greatly improved. Best of all, refactoring code becomes less of a risk with TDD because recursion testing at the unit level is possible.

Here are some tip I would like to share that will hopefully help you make the move to test driven development:
<li>Just do it. Force yourself to write your unit test first. Over time the quality of the unit test will improve, writing unit test will be easier, and it will because almost second nature for you to start with a unit test.</li>
<li>When testing data changes to a database, start a transaction in the SetUp of the unit test and roll back the transaction in the TearDown. This provides an easy way to clean up the data after each unit test.</li>
<li>Writing a unit test prior to writing the production code will give you insight into the design of your class or function. Use this insight to improve on the design prior to writing production code.</li>
<li>Use composite unit testing to test implementors of interfaces.</li>
<li>Write a unit test for each defect reported. This provides a great way to ensure a problem never reoccurs. And for those who already have existing applications but no unit tests, this approach will give you an introduction to writing unit tests.</li>

Posted in uncategorized. Tagged in .