Crude Java and Agile thoughts
TDD – A Bliss Named Test Driven Development
My tryst with TDD (Test Driven Development) started around 2 years back, when my tech lead told me to try to code this way. The first feeling was of shock. I admired my lead a lot due to his immense technical capability. So, this process centric stuff didn’t suited his style of work. Most of the time he gave us all freedom to do a job. So, he specifying a process to write code looked a bit confusing to me.
However, I tried to follow his advice (guideline ;)), at least few times, but never found anything fruitful from it. Those days I was using Agile but not Extreme Programming. So, the tryst with TDD didn’t lasted long as I was never able to utilize it judiciously. The end result of following this practice was not coming clear to me.
Later, I changed my company. The new (present) company was a veteran in Agile and Extreme Programming methodologies/practices. So, I learned to pair program. Learned to re factor. Learned to not do the complete designing at once. Learned to do upfront designing.
Here the emphasis on junit test writing was enormous . So, I sharpened my skills on junit test writing and after a while, I was able to write junit tests pretty easily.
However, the path to excel in writing junit tests is not that easy. You need to travel a painful road of learning all the mocking frameworks and how to use it. And trust me, mocks suck. But, they can take you out of very difficult scenarios. Dependencies on databases, dependency on third party services and other stuff can be managed quiet well by mocks.
Other than mocks, you will also need to learn some workarounds for some complex scenarios which you will face while writing junit tests. I am talking about java techniques here. Like using some anonymous inner classes with behavior suiting the test. Reusing code in tests etc..
So, lets get back to my story.
Even after mastering the junit writing techniques ( which I got by pair programming with some veteran creatures ), I was not able to appreciate the idea of writing junit tests. It merely looked like a figure to satisfy the customer’s quality demands. So, basically, I was not doing TDD till now. Till now, I was doing DDT, which we named ( light humor intended ) as Development Driven Testing. This type of junit tests are written after writing the code which can be described in a plain and simple word “Useless”. This is simply of no use, don’t write it.
So, finally I was shown the magic of TDD when I paired with a pro TDD guy to develop of feature. Earlier, coding without a design in mind seemed hard to me. As I was not able to think of the minute component with getting the big picture. This was the place where I found TDD useful for the first time. The junit test acted like a client which wanted to use the method exposed. Doing development in TDD fashion, finally helped me think of components as needs of the client ( the user of the code being written , in terms of code).
What method needs to be written and what behavior it should attain were also governed by the junit tests. So, the only thing you should know before doing Test Driven Development is the business requirement. You write the requirement and then code for it.
So, these are the test cases which have some meaning attached to it. As some business value was thought of while writing them. So, if they don’t execute successfully, the code is not meeting up the requirements.
With time, I saw the comfort that TDD provides while coding. It takes out the burned of thinking about all the ifs and buts that you have about the execution of the code. As you are testing it as you write it.
The only other important thing that I would like to emphasize is the importance of pair programming in Test Driven Development. Until and unless you will pair with someone who is a master of TDD, you will not be able to appreciate its value. If you don’t have any skillful guy who can do TDD, pair with anyone and try to experiment with it, by just following the rules of TDD.
Execute it correctly and believe me, you will find a bliss named “Test Driven Development”.