Re: A critique of test-first...

From: Jeff Grigg (jgrigg_at_mo.net)
Date: 11/21/04 

Date: 21 Nov 2004 10:31:04 -0800

>> --- CTips <ctips@bestweb.net> wrote:
>>> I'd still like to hear your thoughts on why you think the "shape"
>>> of a program comes out better when you do it with TDD than when
>>> you do it with up-front design.

I too, have been meditating on this question. (And a good question it
is!
;-) But I'll emphasize a different angle than Ron:

The Test Driven Development approach enables and requires you to think
about and work on your design throughout the development process,
rather than doing it just once and having to get it right the first
time.

Even if the requirements, resources, and technical constraints are all
known, up front, and never change through the life of a project, and
even if we do a great job of up-front design, we'll still learn things
as we do a project. Our vision of how things might work in the future
can never be as good as our observation of how things are working
right now. And our introduction of automation into a process always
changes the process, often producing unexpected new requirements and
opportunities for further work.

So there's a lot to be said for the value of flexibility.

I've been programming since '76; professionally since '81. I've been
quite successful with plan-driven "big design up-front" projects for
my entire career. But I also see their weaknesses and failures: Even
when a "perfect" system is built, the business has often "moved on,"
and needs something different than what was originally planned.

So why do I think that TDD produces better designs?
Well, because I've seen it.

I was extremely skeptical of this XP (and TDD) thing some years ago
when I first heard of it. It defies a lot of widely held wisdom on
how to develop software successfully. But I've found that in my
experience on quite a few projects, I've never seen a program that
couldn't have its design improved, often substantially, after it was
successfully delivered. TDD encourages this practice and makes it
safe: Strong automated regression tests make refactoring safe.
Without them, you have to spend an inordinate time retesting all
possible uses of every function that you change in a system. I've
found that this is a hidden cost of maintenance that few people
recognize.

I, personally, have only been able to apply TDD techniques on small to
moderate size systems and subsystems over the past few years. But the
improvements have been visible and dramatic. What I've experienced
and what I've heard from others gives me confidence that these
techniques would serve large projects well.

Here's something that struck me early on about the effect of TDD on my
designs: In addition to the "continuous design improvement," TDD
enables, I found that using TDD gave me a very strong motivation to
separate business logic from database access logic in my programs.
Now three-tier models, which separate user interface, business logic,
and database access, have been popular for some time. And most people
know that they "should" separate their code cleanly on these
boundaries. But I found that when doing Test-Driven Development on my
business logic, life was much easier for me when I separated the
business logic from GUI complexity and database setup and operation
complexity, and made it much more independent. When I sat back and
looked at it, I found that I had a much more modular design. This was
good.

Further, a manager from a large Saint Louis company recently gave a
presentation on a few dozen projects he's run over the past few years,
both with and without XP. He collected good metrics (which we're
still trying to convince him to publish!!!) showing that the XP teams
were more productive. Wondering about design, he drew UML package
dependency diagrams for two of the XP projects, and found a remarkably
healthy package dependency structure. IE: There were few
dependencies, and no circular dependencies. The pursuit of
refactoring to eliminate perceived design "smells" can produce good
results, in terms of overall design.

--- CTips <ctips@bestweb.net> wrote...
> Here's a question - what would you do if you were writing an entire
> program yourself? [...]

Yes, I would use TDD. And I have. Using TDD enables me to write the
simplest program that could possibly meet my needs quickly, and expand
it safely and reliably to cover whatever cases I may have missed. TDD
enables me to improve my design over time. And I've found that even
the best of my designs can be improved over time, when I put my mind
to it.

Not long ago (relatively speaking ;-) I was given a short coding
assignment to complete for an interview. (I and others thought it was
silly to give a coding test to people of our level; but that's another
issue. ;-) The task was to write a small utility to display random
"Magic Eight Ball" answers, selected from a user-configurable set,
with user-defined probabilities for each. I wrote mine using Test
Driven Development techniques. The client said that this was the best
implementation they had ever seen. While they found serious design
limitations and bugs in all other entries, the only criticism they
could level against my implementation was that I had (quite
intentionally) used a simple interpretation in a place where the
requirements were vague, instead of putting in something complicated.
Test Driven Development gives me the confidence to know that if the
customer wants me to add something complicated, I can easily do so --
with very high confidence that I won't break anything else. And if I
had guessed wrong in putting in features that were not asked for, that
could have been bad too.

See "JeffGrigg-Magic8Ball.zip" in
http://groups.yahoo.com/group/extremeprogramming/files/

Relevant Pages

  • Re: code portability
    ... familiar with Test Driven Development as a way of enhancing the quality ... both in design and implementation. ... Kindly take your TDD proselytizing to a newsgroup where ... Typical knee-jerk reaction of an anonymous closed mind. ...
    (comp.lang.c)
  • Re: code portability
    ... familiar with Test Driven Development as a way of enhancing the quality ... both in design and implementation. ... Kindly take your TDD proselytizing to a newsgroup where ...
    (comp.lang.c)
  • Re: XP Requirement Analysis?
    ... tests before TDD. ... Analyze design code debug test. ... write the correct assertions to analyze the output. ...
    (comp.object)
  • Re: Writing a DAL with TDD
    ... idea (to design a relational database based almost exclusively on how it ... Obviously a database should be designed after how it will be used. ... that real-world representation of the business model in the database. ... However when you set out with TDD, ...
    (microsoft.public.dotnet.languages.csharp)
  • TDD sucks [Was: Snake Oil]
    ... TDD is both a low-level design technique and a high-level requirements ... and refactoring to improve the structure and emerge a design. ... The requirements analysis technique makes a project ... they balance the weaknesses of other best practices, ...
    (comp.object)