http://www.infoq. com/interviews/ coplien-martin- tdd
Summary
Debate sprang up at JAOO ‘07 around Bob Martin’s assertion that
“nowadays it is irresponsible for a developer to ship a line of code
he has not executed in a unit test.” In this InfoQ video, he debated
with Jim Coplien on this and other topics, including Design by
Contract vs. TDD and how much up-front architecture is needed to keep
a system consistent with the business domain model.
Bio
Bob Martin is an Agile Manifesto author, and author of books on Agile
Programming, XP, UML, O-O Programming, and C++. He is CEO and
president of Object Mentor www.objectmentor. com/ Jim Coplien is a
software pioneer in o-o programming and C++ and multi-paradigm design.
He appreciates the human side of design, and has written critically
acclaimed books on design and development.
Excerpts:
B: So I have 3 laws of test driven development. The first one is: 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…
J: Per se, the main concerns I have about TDD are not problematic with
respect to what you’ve just said in isolation, so if it’s no more and
no less than that we may not have a big disagreement. What my concern
is, then, comes out of doing broad work with a lot of clients and a
little bit of interactions with other consultants and other scrum
masters who have seen these things happening in their project. And
we’ve seen 2 major problems: one is that use of TDD without some kind
of architecture or framework into which you’re working – which was
very strongly Kent’s original position: you use TDD to drive your
architecture – leads to a procedural bottom-up architecture because
the things you are testing are units.
We just had a discussion upstairs about “is TDD the same as unit
testing?” Well, no, it’s a little more, but unit testing was a great
idea in Fortran, when you could build these layers of APIs and the
units of organization of the software were the same as the units of
testing, but today the units of organization of the software are
objects and we’re testing procedures and there is a little bit of a
mismatch. Now, if you are using the procedures to drive your
architecture, I think you are trying to build a 3 dimensional
structure from 2 dimensional data, and you end up going awry. And 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 and this is
what Trygve [Reenskaug] and I talk a lot about, because 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. I mean even Kent, as he’s very often
said: “you can’t hide a bad architecture with a good GUI.” The
architecture will always shine through to the interface, and I
strongly believe that, and that is why I believe we need something in
the infrastructure that gives you a picture of what the domain model
is out at the interface. Then, if I want to apply Uncle Bob’s 3 rules
I probably don’t have a problem with that, but I want a starting place
that captures this other dimension, which is the structural dimension.
B: Alright. But you do not accept the thesis that the practice of test
driven development is a pure requisite to professional behavior in
2007.
J: I absolutely do not accept that.
