Hi everyone in this article I’m explaining about Test Driven Development.

Description:

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 decide. 

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