Isn’t TDD(Test Driven Development) twice the work? Why should you care?

August 17, 2017 0 Comments

Isn’t TDD(Test Driven Development) twice the work? Why should you care?



TDD: Red — Green — Refractor

The short answer to the first question is NO. On the surface it may seem like without TDD, time is only required to create the feature, and with TDD, you need time to create the test AND create the feature, thus doubling the development time required. What is not being considered is the amount of time required for QA testing and debugging when the feature isn’t performing properly.

Case studies were conducted with three development teams at Microsoft and one at IBM that adopted TDD. The results of the case studies indicated that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD, credits : Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie Williams

That 40–90% decrease in pre-release defects means that QA teams and customers weren’t finding and reporting those issues. Engineering wasn’t trying to recreate bugs and develop patches, all of which have associated costs.

Number of Iterations per task

When discussing TDD we consider a task to be a subset of a requirement that can be implemented in a few days or less. TDD software engineers develop production code through rapid iterations as shown in the figure.

Test-Driven Development is an approach to writing software in which the developer uses specifications to shape the way he/she implements a feature. For short, we describe it as the “red-green-refactor cycle”. Before writing any code adding new functionality to an application, he/she first writes an automated test describing how the new code should behave, and watches it turn red (fail to pass). He/She then writes the code to the specification, and the test turns green (it passes). Finally, the developer takes a little time to make sure that the code just written is as clean as possible (refactor).

Automated testing gives your software developers confidence to make changes to the software and to know no bugs were created as a byproduct. Additionally, it allows more agility for developers who don’t hold expert knowledge of the software to confidently modify the source code without introducing error. Some really cool advantages of TDD are:

First, test suites ensure comprehensive test coverage of the codebase, so bugs are less likely to pop up unnoticed. Second, test suites allow developers to work out potential issues before the application is ready to go into production. Finally, because test suites are constantly maintained, they guarantee software quality.

Because refactoring code is a built-in step in TDD, you end up with a much cleaner codebase as you go. Apps built with TDD tend to have less duplication, fewer edge cases that aren’t thought through, and a better overall architecture. The test serves as a specification for what the code to be written should do. As long as you’re writing good stories, your development team should be able to build exactly what you asked for. If your team agrees to use Acceptance Test-Driven Development, you can even write tests that describe how you want it to work in plain English!

Typically when talking tech about software development, there are 2 main types of testing that can be integrated: Functional and Non functional. These two types of testing practices are further divided into numerous types of testing techniques as follows:

And the list goes on

It becomes really important to strategise the testing plan before project commencement since that helps in clearly defining roles and responsibilities of developers with respect to testers when it comes to testing. For example: Unit and Integration tests to be performed by developers before handing out builds to testers and User acceptance testing to be performed by the testers whereas performance testing, UI testing should be done by both etc, find a brief description of a few very important testing methodologies from the above mentioned list that should be included in almost every test plan below:

Unit Testing is a software testing method by which individual units of source code are tested to determine if they are fit for use. Intuitively, one can view a unit as the smallest testable part of an application. Faking, Mocking and Stubbing are indispensable while writing unit tests for the code which has API interactions.

Integration Test involves a combination of two or more “units” being tested. Integration Tests verify that the components of a software all work together or “integrate” appropriately.

Performance testing is a type of testing to ensure software applications will perform well under their expected workload. Features and Functionality supported by a software system is not the only concern. A software application’s performance like its response time, reliability, resource usage and scalability do matter. The goal of performance testing is not to find bugs but to eliminate performance bottlenecks.

A solid TDD approach alarms you about troubles upfront

The benefit of a comprehensive test suite is that it alerts you to changes early. For example, if your checkout flow stops charging users’ credit cards, you’ll know it right away, because the tests will fail. It also means that if someone makes a mistake and something doesn’t work the way it was supposed to, it will be obvious. That’s good, because it will give you a chance to fix it before it goes to production. If it becomes necessary down the road, you can even start a campaign of deep refactoring without fear, because you’ll have an ironclad test suite that will remain green.

When code is complicated, it gets much harder to get anything done, because one little change over here can result in a big problem over there. When following TDD, developers can make changes with confidence and your QA team will catch fewer regressions and in development terminology “time saved is equal to money earned”

Spend the saved time in innovation

If we just adopted a TDD approach, much of this money (time saved as expressed in point 4) could be spent on new innovations instead.

The nightmare of any project manager is scope creep — any unexpected growth in the scope of work which leads to delays in project delivery. Scope creep can happen for various reasons: poorly defined tasks, misinterpretation of project requirements, lack of documentation, etc. There are many methods aimed at mitigating scope creep, and TDD is one of them.

Thanks for reading, please share it if you found it useful :)

Tag cloud