InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Test Driven Development Has Become the Norm

Posted by Deborah Hartmann Preuss on Jun 27, 2006

Sections
Process & Practices,
Architecture & Design
Topics
Agile Techniques ,
Methodologies ,
TDD ,
Agile ,
Programming ,
Testing
In a recent article on Dr. Dobbs' Portal, Scott Ambler has written an article entitled: "Test-driven development is the combination of test first development and refactoring.

Test First Development is an evolutionary development technique where you write a unit test before writing just enough production code to fulfill that test. Refactoring is a development technique where you make a change to the design of your code or database schema which improves its quality without changing its semantics. Test Driven Development (TDD) combines these two.  When applied in a disciplined way, TDD has been shown to produce many benefits, including significantly increased software quality and improved response-time for software teams with volatile codebases, which otherwise would degrade and slow the team down.

In his article, Ambler addresses five commonly heard objections, explaining how they are based on misconceptions:
  • You create a 100-percent regression test suite.
  • The unit tests form 100 percent of your design specification.
  • You only need to unit test.
  • TDD doesn't scale.
Ambler finishes with:
"My experience is that TDD has become the norm within the agile software development community and has also been adopted by many "traditional" developers as well. TDD should be seen as complementary to modeling approaches, and as I've argued with AMDD the two can and should be used together. TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing."
Note, this is an interesting balance to his statements in January, which were widely (mistakenly?) perceived as denying the need for traditional testing. See Floyd Marinescu's first-person account of the meeting.

So, should you explore TDD now, or wait until competetive pressure makes it necessary? Ambler's article lays out some reasons to consider it.

Read more on testing.
To obtain good code, writing tests and code is faster then code alone by Dan Bunea Posted
Re: To obtain good code, writing tests and code is faster then code alone by Geoffrey Wiseman Posted
Re: To obtain good code, writing tests and code is faster then code alone by Deborah Hartmann Posted
  1. Back to top

    To obtain good code, writing tests and code is faster then code alone

    by Dan Bunea

    In the community there are huge missconceptions regarding agile practices, and unit tests and TDD seem to be the same in most people's minds. Could it be the name? Test Driven Development ?

    Ron Jeffries, said this on the TDD yahoo mailing list a few months ago. Trying to prove it and to show that TDD actually scales much better then anything else I wrote a small experiment at: danbunea.blogspot.com/2006/06/to-obtain-good-co...

    For tests there are also good practices, that need to be followed, and I also found a great test practice patterns, collected by Gerard Meszaros is at: xunitpatterns.com/

    Dan

  2. Back to top

    Re: To obtain good code, writing tests and code is faster then code alone

    by Geoffrey Wiseman

    I'm inclined to agree that in order to obtain some of the qualities of what one would normally consider good code (well-tested, maintainable), writing tests and code together is often a faster route to that end.

    That said, there are a number of circumstances in which a business might choose to do without some of those qualities; I'm inclined to believe this happens too often, but I'm also inclined to believe that it is, most of the time, a business decision.

  3. Back to top

    Re: To obtain good code, writing tests and code is faster then code alone

    by Deborah Hartmann

    > I'm also inclined to believe that it is, most of the
    > time, a business decision.

    Geoffrey, do you mean "a bean-counter decision" as in "it has to be cheaper to have twice as many people coding" ? Or something else?