Introduction of Test Driven Development (TDD)
Hi everyone in this article I’m explaining about Test Driven
Test-driven development (TDD) is an evolutionary approach to
development which combines test-first development where you write a test before
you write just enough production code to fulfill that test and
refactoring. What is the primary goal
of TDD? One view is the goal of TDD is
specification and not validation. In other words, it’s one way to think through
your requirements or design before your write your functional code (implying
that TDD is both an important agile requirements and agile design technique).
Another view is that TDD is a programming technique. The goal of TDD is to
write clean code that works. I think that there is merit in both arguments,
although I lean towards the specification view, but I leave it for you to
Why TDD? What’s the Problem with Traditional Approach?
To answer your question, let me remind you first “No process
in this world is the best in all cases”. Every process has its merits and
demerits. Even if nowadays waterfall model is appropriate for some kind of
systems. So my focus is not TDD is best over non-TDD approach. Rather TDD
offers some sort of benefits that we can leverage:
1. Automated testing:
Now days as system is getting bigger and complex, people are moving to
automated testing. Automated system makes the testing much more easier and
faster. Manual testing is slower and needs human interaction which is
error-prone. Automated testing makes sure any particular test is not missing
every time we test the system, whereas human may leave a test out mistakenly
during testing process.
2. Better to test New/Modified Functionality:
With manual testing whenever you add new functionality or modify existing
functionality, QA personal needs to test all systems that may be affected due
to the modification which may be time-consuming. This may also leave a hidden
bug in the system after modification. With TDD whenever a new functionality is
added or existing functionality is modified, the whole set of tests in the
system is run to make sure existing tests are passed. This makes sure that
existing functionality is not broken.
3. Developer’s confidence: With TDD, developers
are more safe to change the system as any inappropriate changes will make some
tests to fail. With non-TDD system developers needs to take more care to change
existing system as the new change may fail other functionality. But with TDD
developers can do so easily as after modification if developer runs the test
he/she will find immediately that the change has failed some other tests (i.e. some
other part of the system).
4. Manual testing stage is shortened: In non-TDD
development, as soon as developers prepare a build, QA personal starts testing.
This manual testing takes a reasonable amount of time and increases the time to
deliver the product from the build time. With TDD, a major part of the system
is tested during development and needs lesser QA involvement in the time between
build and final delivery of the product.
5. Alternative Documentation: Unit tests are kind
of documentation to system. Each unit test tells about an individual
requirement to the module or system. For example, the following test ensures
that only a logged in user with proper balance can buy an item when the item
exists in stock. This test reflects a user aspect scenario of the system.
TDD and Traditional Testing:
TDD is primarily a specification technique with a side
effect of ensuring that your source code is thoroughly tested at a confirmatory
level. However, there is more to testing than this. Particularly at scale
you’ll still need to consider other agile testing techniques.
With traditional testing a successful test finds one or more
defects. It is the same with TDD. When a test fails you have made progress
because you now know that you need to resolve the problem. More importantly,
you have a clear measure of success when the test no longer fails. TDD increase
your confidence that your system actually meet the requirements defined for it
that your system actually works and there for you can proceed with confidence.
Test-Driven Database Development:
At the time of this writing an important question being
asked within the agile community is “can TDD work for data-oriented
development?” When you look at the process depicted in Figure 1 it is important
to note that none of the steps specify object programming languages, such as
Java or C#, even though those are the environments TDD is typically used in.
Why couldn't you write a test before making a change to your database
schema? Why couldn't you make the
change, run the tests, and refactor your schema as required? It seems to me
that you only need to choose to work this way.
In my next post I’ll explain about Using TDD with in ASP.NET MVC