TDD When to and When not to

TDD When to and When not to
From Programmer to Programmer

1. What is TDD?
TDD is Test Driven Development, a software development technique that relies on the repetition of a very short development cycle: First the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. (http://en.wikipedia.org/wiki/Test-driven_development)

2. When to use TDD
2.1 Productivity and Quality are must-have
TDD is a way to design software for testability. TDD ensures all code is covered by tests. Moreover, testing and debugging each small part is easier than testing and debugging the whole system.

With TDD, developers spend more time for testing, and less time for coding. As developers write unit tests for their own code, and only the necessary codes are written to pass the test, TDD means quicker, goal-oriented, cleaner and simpler coding. In addition, developers are kept on track.

Well-written unit tests can be used as an important part of documentation ? reduces document.

So, TDD makes software more stable, reliable and testable.

2.2 Goals and Requirements are clear and fixed at the beginning, or rarely and slightly change
In TDD, developers refactor their code to improve it while keeping the functionalities. If there is no clear goal or requirement, it is not only troublesome to decide with test should be used, but refactoring may also be a nightmare when functionalities are totally changed.

With TDD, when there’s a new implementation, the first thing to be considered is how it will be used, not how to build it nor how to implement it ? more user-oriented. However, a clear goal with detailed requirements is preferred. If how user interacts with the new implementation is unknown, we can not use TDD.

2.3 Developers are experienced in testing
One good thing about TDD is that developers must fully understand requirements to write tests.

Another good thing about TDD is that there are many testing tools that help developers save time and effort.

3. When not to use TDD
3.1 Experimentation and thrown-away products, they are for understanding, learning new things or getting feedbacks
Application Development is driven by Test, not by Usability or Scalability… while they may be things that we want to get feedbacks.

TDD slows down the process as many refactoring have to be done during developing. In case of experimental products, time and effort are essential.

3.2 Agile Development, when there are a lot of unknown
Changes of UI and API often cause tests to fail.

TDD requires a clear goal, but in Agile Development, requirements are unclear and often change. Therefore, every time requirements are changed, tests need to be rewritten.

3.3 Developers have no or few experiences in testing
If developers have no skill in testing, it may happen that unnecessary tests are written, or the whole system is not test-covered. And both cases promise no good things.

It is nearly impossible to measure how many tests are enough or how to 100% tests the system. Poor design will lead unnecessary tests. It is a waste of time, money and effort.

Integrated (and complicated) test must be also considered. Other while, all parts may pass the test but the whole system does not.

It is hard to write test for Interface, Database, and Concurrent Programming.

Good unit tests require testing skills and experiences. Testing a whole system need various testing techniques and testing tools.




Bibliography

1. Functional Test Driven Development, http://bizdriven.blogspot.com/2005/11/functional-test-driven-development.html
2. If you do Test Driven Development all the time, you’re doing something wrong, http://www.thekua.com/atwork/2008/02/if-you-do-test-driven-development-all-the-time-youre-doing-something-wrong
3. Introduction to Test Driven Design, http://www.agiledata.org/essays/tdd.html
4. Kiessig, R. (2007). Companywide cumulative Test­Driven Development.
5. Sinaalto, M. (2006). The impact of test-driven development on design quality.
6. Test Driven Development - Is it good or bad?, http://msmvps.com/blogs/paulomorgado/archive/2007/03/29/test-driven-development-is-it-good-or-bad.aspx
7. Test Driven Development, http://pooya.khamooshi.com/Pages/MyArticles/TDD.aspx
8. What’s the best argument to convince developers to learn TDD?, http://stackoverflow.com/questions/913458/whats-the-best-argument-to-convince-developers-to-learn-tdd
9. When TDD Goes Bad #1, http://weblogs.asp.net/jsgreenwood/archive/2004/11/26/270503.aspx
10. When TDD Goes Bad #2, http://weblogs.asp.net/jsgreenwood/archive/2004/12/29/343963.aspx
11. Y. Dubinsky and O. Hazzan. (2007). Measured Test-Driven Development: Using Measures to Monitor and Control the Unit Development. Journal of Computer Science