Being Test-Driven
NUnit and other popular and freely available unit testing frameworks have been here for enough time for people to absorb unit testing in their .NET development environments. Does just having parallel NUnit test cases for your code suffice to being truly test driven? In the following sections, I have tried to put down what I think about this whole thing.
Putting the very tenets of test driven development at the outset, the answer would be a straight ‘No'. So, what are these tenets? In my opinion, the most important tenets are:
- Test-First development
- Designing for testability
Test-first development did not make sense to me at first. The very concept of writing unit test cases before writing the application code, appeared to be against the norm. But if you take a hard look at it, you will see a value in writing test cases upfront. You will realize that it is the best scheme in building confidence in the code you are going to construct. Test cases built that way would be the guardian angels of the quality of code you write. In fact, I have started to believe that writing unit tests after you have churned out all the code does not add any value. You would be better off just testing manually - either running through the system's functionality or by just walking through the code. The reason being you, as a developer, would be more biased towards what the code does, rather than what it should actually be doing.
Like test-first development, designing for testability is not something that is typically at our disposition. Well, it is not any new model of design per se; it is just about taking your design and then asking these questions- is this suitable enough for me to write test cases against? Is it possible to create atomic units that can be tested and verified in isolation? This is definitely not as easy, as we typically tight-couple the layers in our application, rendering them difficult to test them as separate units. Design weaves the fabric of the application and hence, this tenet should be treated with a lot of importance. Because, having a design that makes it difficult to test individual units defeats the very purpose of unit testing.
Test-Driven development is a journey that I have embarked upon, and it is not going to be rosy to start with. The slogan - Red=>Green=>Refactor=>Test-Driven is all planted into my workplace, but I know, it would take more than that to imbibe it wholly into my daily work. But, I shall get there eventually.
So, are you ready to be test-driven?