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