Test driven development is a method of software
development typically followed in teams adopting the ‘Agile’ software
development model. TDD requires the tests to be written first then the
functionality being coded for the tests to pass. This implies that each new
line of code being written should have an already existing and failed test case
for it.
The following figure represents a typical TDD
workflow:
First of all, tests that need to pass are
identified for the given functionality are identified and coded in the
programming language or the framework of choice.
Then the code is written to make the tests written
for the functionality pass.
After the code is written for tests then the tests
are executed to check if the tests pass. If the tests pass then the new tests
are written for new functionality in the application else the code is fixed
to make the existing tests pass. This cycle is repeated over the entire
application development life-cycle.
A programmer following a TDD approach is likely to
refuse to write a new function/line of code until there is an existing test
written for it.
By default the source code generated using the TDD
methodology is more thoroughly tested and the confidence level is much higher
than the model oriented development approach.
TDD ensures that the code is unit tested and the
code coverage is 100%.
The chances of scope creep by the developers are
also minimized as the pre written tests tend to prevent it.
Over the period of time the adoption rate of TDD
has been comparatively low due to various reasons. Some of the reasons include
the myths associated with TDD methodology, such as:
Scalability issues: The scalability issues may be
due the tests taking a long time to run especially in large projects.
Training needs: In terms of the effort required to
train the team on how to write good tests. Developing the test writing skills
is an incremental process at it takes its own time to mature. It just cannot
happen overnight.
Technical Challenges: There could be technical
challenges as well for example writing tests in the multi-threaded environment
could be very challenging and may not be the ideal approach to be taken.
Resistance to Change: every new way of working is
opposed.
Religious Refactoring of the Code is essential and
would be required at every milestone. In case of change of the application
logic the tests need to be updated accordingly which might be a big overhead
for large and complex projects.
TDD is often thought to be the complete solution for
software quality and people perceive that other software testing verticals are
automatically taken care of. However, the fact is that TDD may yield a
perfectly unit tested code with greater conformance to the specifications, but
the need of all the testing verticals is very much there. The functional
regression, the performance and the load testing, and the security testing
functions will always have to be there to support the over all quality of the
product being developed.
So TDD has both its pros and cons, and you nee to
weigh them before going TDD.