Posted by: Rajesh Kanaparti | March 15, 2008

Test Driven Design = TFD + Refactoring

One of the good practices that we pick up when adopting agile methodology is Test Driven Development . Would like to discuss the benefits and practices of such an engineering practice.



First thing first, what is Test Driven Design and what benefits can we get?


Test Driven Design can be summarized as writing small functional unit tests possible to test a an intended behavior( aka Test First Development) and in this process writing less cohesive code using good refactoring.This is just opposite to the conventional way of testing the code as a whole once all the development is done.



What is a Unit Test?

A unit test is a piece of code written by developer who exercises a small, specific area of functionality In the code being tested. This will re-instate and give confidence to the developer to quickly check if the code is doing what it is really intended to do.


Now don’t get carried away with functional and performance testing. Nope unit test is not going to test those aspects of your code. It simply check the logic that the developer wrote.


Thinking about the excuses not to do it? Let me help you come up with some excuses that I came up with When I first started learning about the practice.


It takes too much time to write the code and its tedious.

Exactly! That’s what I think. But learned quickly that this is not the case.

For example, I started developing a code with a set of requirements that the user requested.

I completed writing the application and deployed it. When I started testing, I quickly discovered that I missed a requirement. But I also built other modules that depend on this module .After spending some time quickly was able to trace the problem but went backwards and some times the requirement might need to change the way I designed some of the objects or methods or interfaces.



Lesson Learned: Its easier to fix a problem when it is small and clear on your mind than going through complex modules and guessing where it went wrong after completing a complex module. This thinking amazingly also helps you design good software and improves the quality of the code.



Another good excuse, the project that I am currently working on is complex and developed by another team and is not easy to develop unit tests. Well I was there and in my situation whenever I have to fix a bug, I have to go hunt all over the code and its not easy to do that when you are working on a complex system. Well I fixed the bug. But now that I introduced new code for the bug fix, some where in your mind you get a feeling that warns you if the fix didn’t break any other existing functionality. Did you get that weird feeling when you are deploying the code for testing.



Lesson Learned: Yeah time after time, I found that when ever I touched an existing code, I tried to write unit tests for that small part that I am fixing. This some times need some refactoring but at the end I have more confidence on the fixes that I made. I was able to refactor the code that made the code look elegant and easier to follow. So when you are maintaining legacy system, start at a point where you touched the code and slowly develop start developing unit tests.


I am a developer and testing is not my style. Its boring and manual.Right, I agree with you partially. But how many times did you see tester feel proud of themselves when they find a bug in your code. And you might quickly recall how stupid you feel for some of the bugs they find. Well to maintain your style and confidence , unit testing can help you. Again personally for me doing things with confidence is a great feeling that I don’t want to miss even if it takes little bit more work. Besides if you are in a agile team. It doesn’t matter if you are a developer or a tester, you are a member of the team which is self organized and you should do your best to make the team successful by completing the sprint backlog in time while following best practices.



And for the managers, it is a quality factor and peace of mind that reduces the project risk. They can report to the Sr. Management/ Client that how much of the code is being unit tested and how it improves the quality of the product.



That is all well and good but what to test and where to start? Will be discussed in the next post.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: