Nigel Cheshire

Subscribe to Nigel Cheshire: eMailAlertsEmail Alerts
Get Nigel Cheshire: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

JavaOne - TDD Controversy

TDD is a big topic with plenty of reference material available on the web, and people interpret parts of it differently

Nigel Cheshire's Blog

Reading Joseph Ottinger’s blog; “Scary thought: maybe those who say they can’t do TDD are right” I would think that any development manager or newbie looking to implement TDD would be pretty concerned about some of the comments made, particularly this one:

“Most developers do *no* TDD at all. It's about time we started listening to these people instead of trying to lecture them.”

Obviously this is a controversial issue. It can quickly degenerate into a tirade of arguments about why TDD would or would not work in certain organizations and types of projects.

The obvious thing I see here is an education issue. TDD is a big topic with plenty of reference material available on the web, and people interpret different parts of it in different ways. Sure, some people may have had bad experiences with TDD depending on the culture of the organization, especially if they are not fully committed to a TDD approach, which can quickly result in them slipping back into more traditional development methodologies. Or, from a technical standpoint, some organizations find it difficult to implement a TDD approach in, say, an embedded environment.

However, the organizations I have seen that have successfully implemented a TDD methodology are the ones willing not only to invest the budget to train people in TDD and its culture, but to have the patience to work through the first months of hurdles and issues due to the different way of thinking that TDD requires.

The whole ‘agile revolution’ is not a silver bullet, but there are an increasing number of reports and case studies (for example: Success Rate of Agile Software Development in Agile Magazine - Spring ed. or http://www.objectmentor.com/omSolutions/agile_customers.html ) on many projects that show an increase in the number of projects being delivered on time and at a higher quality level. TDD is a big part of this revolution.

There are various ways to implement TDD, and a number of different keys to success. A simple favorite of mine is this: if a bug is reported, write a unit test to prove the bug exists. Once the unit test passes, the bug will be eliminated and should never re-occur [assuming you run all unit tests as part of your integration build].

A reference work I see on the desks of nearly all customers I visit is Michael C. Feathers’ Working With Legacy Code”, which has many examples of applying TDD to legacy projects, rather than only new projects, something that was missing from a lot of last year’s conference topics when discussing TDD, in my opinion.

More Stories By Nigel Cheshire

Nigel Cheshire is CEO of Enerjy Software, a division of Teamstudio Inc. He oversees product strategy and has been driving the company's growth since he founded it in 1996. Prior to founding Teamstudio, Inc., Nigel was co-founder and principal of Ives & Company, a CRM solutions consultancy. He holds a Bachelor of Science degree in computer science from the University of Teesside, England.

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Dave Wilson 05/15/07 01:49:09 PM EDT

TDD can work even with $DD. In my experience, you will actually get your code working faster by writing unit tests before, or immediately after, your write a section of the code. By testing each component as you go along, you are less likely to build a house of cards - i.e., you have a solid code base to build upon.

Don Babcock 05/15/07 10:22:36 AM EDT

I see from the feedback that TDD="Test Driven Development." Nice concept. Reality intrudes however. In every shop with which I've had the pleasure of exchanging $ (salary) for skill, all development was ultimately DDD or $DD (Dollar Driven Development.) Those two break down into CDD (customer driven development) and PDD (politically driven development) mixtures. Consulting gigs tend to have more of the former. Corporate gigs typically major in the latter. In 35 years in this biz in numerous organizations spanning fields from Aviation to Utilities I've yet to encounter one that does TDD. I think that is largely because of the "T." Testing implies a standard, a requirement, if you will. Tests logically (therein lies the rub) descend from requirements (R.) Frankly, most organizations don't really know what they want "but they'll know it when they see it." Doing the "T" is easy if you know the "R" in any definitive sense. Any kind of "T" without the antecedent "R" is meaningless. So that drives us back to "RDD" (requirements driven development) which is nothing really new. Rather, it is the "holy grail" for which developers have always longed. In my view, the principal value of TDD is the extent to which it drives toward clarity and definition of requirements. The downside is that a developer can become overly fixated on the "T" and lose sight of the "R."

But I'll grant you this, if you can get your organization to "buy into" TDD, you will have effectively tricked them into solving the real underlying problem. You will force them to derive and state their actual requirements (the real issue, always has been) by working backwards from the "tests." Oh yes, you'll enjoy all of the QC benefits of built-in regression testing as well but the real benefit will be the generation (albeit from the back to the front) of actual requirements. That has always been the "hard" part. Sadly, I suspect that you will find most organizations suprisingly inventive in developing new ways to avoid this "pain" even while paying lip-service to TDD. To the extent they succeed, your TDD effort will fail.

Don Babcock 05/15/07 09:34:16 AM EDT

In vain did I search your article for the definition/expansion of "TDD." That oversight rendered the article worthless to me for information. To get an idea of how such an article reads, just read it substituting "blah" for every instance of TDD. I couldn't even infer it from the context. Friendly tip, never assume your audience is up to speed on all the current jargon. We read such articles to keep up with it. My practice in writing on technical subjects is to ALWAYS fully qualify acronyms on their first use in an article.

Dave Wilson 05/14/07 09:07:15 PM EDT

TDD = Test Driven Development. Write the tests before you write the code. If you write a test for each requirement, this makes it more likely that you actually implement the requirements.

Dave Wilson 05/14/07 09:05:09 PM EDT

If you can't implement TDD on an existing project, that may indicate a fundmental defect in the design - i.e., the code isn't testable. Focusing on TDD from the beginning of a project leads to testable code - this likely pushes you toward a more well-factored design.

Gerry Matte, IT Manager 05/14/07 07:23:30 PM EDT

Perhaps I don't spend enough time reading blogs and keeping up on issues ..... exactly what is a TDD ? The acronym is used frequently in the article and in the headline with nary a clue why I should care .....

Java News 05/11/07 06:32:24 PM EDT

The obvious thing I see here is an education issue. TDD is a big topic with plenty of reference material available on the web, and people interpret different parts of it in different ways. Sure, some people may have had bad experiences with TDD depending on the culture of the organization, especially if they are not fully committed to a TDD approach, which can quickly result in them slipping back into more traditional development methodologies. Or, from a technical standpoint, some organizations find it difficult to implement a TDD approach in, say, an embedded environment.