Benefits of Test-Driven Development

Benefits of Test-driven development

In the last article, we discussed the process of Test-driven Development. Once we understand the process of Test-Driven Development, it is time to understand the benefits of Test-driven Development.

So, before considering the benefits of Test-driven Development, let us consider some of the common issues faced by the developers/testers.

Traditionally, the Developers design & develop Classes/Methods & hand over it to the Testing team. By the time the Testing team finds defects, the implementation of the Class or Method is already complete, or worse, additional code is written on top of it. So, if the Testing team informs the development team of the bug with this time delay, there are a few undesirable things that happen:

  • Many days elapse between the day the code was written and the day the bug was uncovered. More the delay in finding the bug, more the cost of delivering software.
  • The Developer is in a different Iteration1 and he has to context switch from the work done in the current Iteration to the previous ones. Context Switching is a huge cost.
  • The Developer, occasionally, forgets the logic that he previously implemented. So he is forced to think hard to regain his thoughts.
  • The Developer must go back to the code that he wrote in the last Iteration and fix the issue. But other Developers have already written code that uses his Class.

Can you see the problem? Imagine the cost overrun/time delays/Developer anxiety/Testing ineffectiveness?

 

Benefits of Test-Driven Development:

One of the main ideas behind Test-driven Development is to catch bugs as soon as possible. Nip the problem in the bud, they say. Test-driven Development, if correctly implemented, shall solve the problems described above.

Of course, the first main benefit of Test-driven Development is that the bugs are introduced no sooner than they are caught. As the Developer makes the changes, he runs the automated suite created by the Tester to validate his code. The Test would highlight any deviation in implementation from the Acceptance criteria.

The Second benefit of Test-driven Development is that it serves as a guide to Developers writing the code. Sometimes, the Developers think too deep in all directions before implementation, just to get the right architecture. They get lost in the details, over-engineer the code & lose the bigger picture. Test-driven Development is meant to guide the Developers to follow a structured path to completion. Test-driven Development acts as a design tool, where the Developer needn’t think about anything else, but, just write code to adhere to the tests. This helps to have customer focus & value focus at the center. This approach & mentality adds value to the customer.

The other Key benefit related to the above point is that the User Stories are implemented thick & fast as developers need only to think just enough, to pass the test, & not worry about some abstracted architecture.

The third benefit of Test-driven Development is documentation. Suppose, a new Developer joins the team. It will be rather easier for him to go through the tests and get a fair understanding of what a method does, rather than go through the complex logic, which would be very difficult to comprehend.

 

 

Conclusion:

In Conclusion, Test-driven Development solves the problem of developer anxiety as the bugs are caught and brought to his notice when he is still working on that little piece. It solves the problem of Cost Overrun/time delays as the bugs are caught at the earlier stages of development, thereby reducing cost. It also solves the problem of testing ineffectiveness as bugs are uncovered right when they are introduced. The result is a satisfied customer & a happier Development team.

Would you like a 360° view about Test-driven development? Check out this Pluralsight course with a free trial

1 Iteration – An Iteration is a fixed block of time where the team works on a committed number of User Stories2 that provide value to the end user.

2 User Story – In Agile methodology, requirements are captured in the form of User Stories from an end user perspective

3 Acceptance Criteria – The criteria laid down by the customer for the acceptance of the implementation of the User Story.

As always, please leave your comments. I’d really appreciate them.


Want to be notified as soon as I post? Subscribe to RSS feed / leave your email address in the subscribe section. Share the article to your social networks with the below links so it can benefit others.

You may also like

Leave a Reply

Your e-mail address will not be published. Required fields are marked *