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:
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.
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.
"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.
Community comments
To obtain good code, writing tests and code is faster then code alone
by Dan Bunea,
Re: To obtain good code, writing tests and code is faster then code alone
by Geoffrey Wiseman,
Re: To obtain good code, writing tests and code is faster then code alone
by Deborah (Hartmann) Preuss,
To obtain good code, writing tests and code is faster then code alone
by Dan Bunea,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: To obtain good code, writing tests and code is faster then code alone
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: To obtain good code, writing tests and code is faster then code alone
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
> 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?