Home
In traditional software development methodologies, the cleaning of the code – identifying, troubleshooting, debugging, and fixing defects – usually consumes anywhere between 35% to 50% of the time taken to write the code.
This is primarily due to the fact that the code is written independent of the tests and it is verified, using these tests, only at the end of development activity.
If the defects were not allowed to enter into the code in the first place, by writing tests first and coding on the basis of these tests, it would result in an application being delivered faster with lesser defects.
Though it was difficult to be implemented in waterfall model-based projects, it was very much possible in agile-based projects because:
Development and testing are not considered independent activities
They often happen in parallel (Pair programming)
This led to the acceptance and evolution of Test First Development (TFD) methodologies.
The simplest of TFD methodologies is called Test Driven Development (TDD).
Benefits:
-
100% code coverage is always achieved.
-
TDD makes the developer focus on the requirements before writing the code.
-
There is a drastic reduction in the number of defects at later stages of application development.
-
Even though there is a moderate increase in development effort initially (writing tests), overall project effort/cost savings justify it by a significant margin.
Drawbacks
-
The business analysts, who created the software requirements, are not providing feedback to the developers in the TDD process as they don’t have the required technical expertise. Hence, it is possible that:
-
The developer coded excess modules than required (code wastage)
-
The developer did not code some required modules (leading to defects)
-
When functional acceptance tests are run, new defects may be uncovered. This would defeat the objective of TDD as it would initiate multiple defect fixes and defect retest cycles during the acceptance testing phase. By then, it’s very expensive to fix the defect.