BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon San Francisco - image
QCon San Francisco

Level up your software skills by uncovering the emerging trends you should focus on. Register now.

 QCon London - image
QCon London

Discover emerging trends, insights, and real-world best practices in software development & tech leadership. Join now.

 QCon London - image
InfoQ Dev Summit Boston

Learn how senior software developers are solving the challenges you face. Register now with early bird tickets.

 The Software Architects Newsletter - image
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News TDD: Essential Skill or Architectural Landmine?

TDD: Essential Skill or Architectural Landmine?

Bookmarks

Feb 20, 2008 3 min read

Write for InfoQ

Feed your curiosity. Help 550k+ global
senior developers
each month stay ahead.Get in touch
At JAOO '07 Bob Martin asserted: "it is irresponsible for a developer to ship a line of code he has not executed in a unit test." In this twenty-minute InfoQ video, Coplien and Martin Debate TDD, CDD and Professionalism, filmed at JAOO 2007, Martin debated with another well respected software thought leader, Jim Coplien, on this and other topics. Discussion covered the definition of Test-Driven-Design (TDD), whether TDD imposes a procedural approach on o-o design, Design by Contract vs. TDD and how much up-front architecture is needed to keep a system consistent with the business domain model.

Both men are careful about their words and ideas, as displayed in their courteous discourse and the care taken to be clear about terms and concepts. Coplien invited Martin to set the stage by sharing his specific definition of TDD:
Bob Martin: So, I have 3 laws of test driven development:
  1. a test driven developer does not write a line of production code until he has written a failing unit test, and no production code can be written until there is a failing unit test;
     
  2. you do not write more of a unit test than is sufficient to fail, and “not compiling” is failing. So you cannot write very much of the unit test before you must write production code;
     
  3. you cannot write more production code than is sufficient to pass the currently failing test. So you cannot write a little bit of a unit test and then run off and write a whole bunch of production code.

These 3 laws lock you into a cycle that is perhaps 30 second long, and that means you are actually writing test and production code concurrently, with the tests perhaps 30 seconds to a minute ahead. That is my definition.

Although Coplien has been taking issue with XP and TDD in recent months, he asserted that he had no problem with any of these basics! For Coplien the problem seemed to lie in how these are applied within projects, particularly in relation to architecture and usability.

Coplien: ...today the units of organization of the software are objects and we’re testing procedures and there is a little bit of a mismatch. ... one of the things we see a lot, in a lot of projects, is that projects go south on about their 3rd sprint and they crash and burn because they cannot go any further, because they have cornered themselves architecturally. And you can’t refactor your way out of this because the refactoring has to be across class categories, across class hierarchies, and you no longer can have any assurances about having the same functionality.

The other problem we’ve seen is that this destroys the GUI ... you have this procedural architecture kind-of in a JAVA class wrapper; you no longer are driving the structure according to domain knowledge and things that are in the user’s conceptual model of the world, which is where object orientation came from...
After looking at where the problem lies, they did briefly look at the issue of whether TDD is an essential skill for anyone calling themselves a professional programmer these days. Coplien categorically disagrees with this proposal, however when Martin walked him through the creation of a fictitious new system, they didn't differ much in how they would approach it. It almost looks like the trick lies in calling it, or not calling, it TDD - the practices are sound enough in the abstract, but the term TDD itself seems to carry baggage that offends some sensibilities.

Coplien admitted that their positions are not so far apart, summing up it this way:
I think when I am running into people that are doing things right, that avoid the kind of problems [we] talked about earlier, it’s not TDD out-of-the-book or TDD out-of-the-box. So, people have found a way to move to what Dan North now calls BDD, for example, which I think is really cool (if you ignore the RSpec part and all the stuff which is kind of dragging it back to too low of a level).
The short dialogue also touched on Design by Contract and Contract-Driven-Design vs. TDD.

View this short video dialogue between two respected software developers and authors: Coplien and Martin Debate TDD, CDD and Professionalism

Rate this Article

Adoption
Style

This content is in the Software Craftsmanship topic

Related Topics:
BT