Ubuntu insights, Programming in groovy, java, et als!

Thursday, February 02, 2012

The Art of Test Driven Development

For the very for first time, I have dabbled myself into the practices of Test Driven Development. I must admit that I am completely bowled over by the experience. For more than an year, I had been reluctant to adapt the concept of unit tests as I mistook writing them as a programmer's lack of faith in the code he pushes in but I eventually realized that I could NEVER BE MORE wrong.


I have long had this evil habit of quick prototyping where in all I care about is the end result. In this process, what starts off as a script evolves into neatly refactored block closures and methods, methods to classes & objects and classes to packages. In spite of starting to code with a basic design in mind, it becomes very hard to adhere to the architecture and design with this bottom-up approach as it solely aims at achieving a result without considering the means to achieve it. Hence the code quality might short fall of standards as it ought to be. Also, this involves constant rework. Though a quite conventional approach and a pleasure to begin with, this method is bound to inflict pain at later stages when the code base evolves into a dinosaur and becomes hard to maintain.


Test Driven Development on the contrary might seem annoying at the start to code with but eventually pays off. TDD is all about starting to code keeping in mind the unit tests that are going to be written. The core code base and the xunits are written in tandem with each other. They go hand in hand. It appears like programming in two places at a time. You code for a method in the base class and write its corresponding test in the testcase and run it simultaneously. With TDD, it is like thinking in two directions at a time. As a result of coding in tandem with the unit tests, the very initial draft of code itself begins to look like what it would seem to look like after two or three cycles of rework. Very neat, well re-factored, modularized, extensible and testable. The code written in this manner is more reliable because the unit tests enforce the programmer to code keeping in mind the exceptional scenarios, exposing all the permutations and combinations in which a piece of code could behave. As a result of this, the bugs in the final delivery will dwindle down considerably.


The number of unit tests increase over a period of time along with the code. All the testcases written could be run on a periodic basis to ensure that any newly committed code will not break the functionality of the existing code base. This diminishes the scope for regression issues and hence adds to scalability and maintainability of code. 


Very often it becomes difficult for a newbie to get a hang around code that is already written. Even in such cases testcases help because unit tests themselves act as informal documentation to the classes and methods used. Adding to that, as the code grows in size, the need to use a debugger eventually reduces provided the code is covered by diligently written testcases. 

TDD is an elegant art. Practice it! Preach it!, to everyone who aims to be a quality programmer. For, it is a priceless feeling to experience the 'aha' moment when you look at your sexy monstrous code base that says "All tests passed".

1 comments:

Don said...

I came across TTD during Compilers course. When you are writing more than a 1000 loc or more than 10-15 files, you'll be wasting time around strange bugs :D

Post a Comment