When after many years of development, I first came across the test driven approach a couple of years ago, it didn’t make immediate sense. The main drawback seemed to be that there was just not enough time to write the tests. But over time, the key benefits I’ve seen are that it really documents the requirements at a coding level, and it also builds in a looser coupling among modules. And of course automated regression testing is just fantastic – with a well written test suite, one can be reasonably confident that any changes in one module hasn’t adversely affected dependent modules right after a build! (and a test suite is executed as a post-build step!)

On the other hand, I’ve found it pretty challenging as well in many situations – esp in UI development I usually gave up. Sometimes I felt that building up the mock environment to test one particular module just took too much effort to be worth it. Its pretty tempting to bypass it and just get on with development! 😉 But once we see the benefits, it just becomes a matter of discipline for any good developer to start absorbing and cultivating this methodology!

Here is some more info from the web…

Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration’s tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing.

~ Wiki on TDD

Test-driven development (TDD) is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies. The result of using this practice is a comprehensive suite of unit tests that can be run at any time to provide feedback that the software is still working. This technique is heavily emphasized by those using Agile development methodologies. In order to use this technique with Visual Studio Team System, you must understand some other topics:

~ Guidelines for Test-Driven Development – from Microsoft MSDN

And from the same link, here are some of the benefits…

  • The suite of unit tests provides constant feedback that each component is still working.
  • The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.
  • When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.
  • Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it.
  • The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time.
  • The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified.
  • Reduced debugging time!

This gives a nice diagram to explain it better: Introduction to Test Driven Design (TDD)

Further links…

Java Testing

Windows/.NET Testing