"David Lightstone" <david._NoSpamlightst...@prodigy.net> wrote:
>"William Tanksley Google" <wtanksle...@cox.net> wrote:
>>>>>My intent was to indicate the TDD does not provide code structure
>>>>>as a benifit. Because you can inmprove the code structure of the
>>>>>code independent of TDD. (test first or otherwise)
>>>>You *can* improve the code structure independant of TDD, and you
>>>>draw straight lines freehand. Many people find it pleasant and
>>>>convenient to do so. But that doesn't mean that straightedges
>>>>provide line structure, nor that TDD doesn't provide code
>>>>While you're using a straightedge it's hard to get away from
>>>>a straight line; when you're using TDD it's hard to get away from
>>>>writing cohesive modules which are loosely coupled.
>You are comparing a very simple tool (a straight edge), to one which
>claim to be sophisticated. A more appropraite comparison would be to
>something more sophisticated. Something that can readily produce a
>Euclidean Geometry there is no such thing as a curve line.
>geometry is another story
This is pointless quibbling. Look at the question, not the analogy:
you claim that IF there are other ways to produce good code structure,
THEN TDD can't claim good code structure as a benefit.
I point out that straight lines are a benefit of using a straightedge,
even though there are other ways of getting straight lines. In the
same way, good code structure would be a benefit of TDD regardless of
whether there were other ways of producing it.
I wonder whether you're trying to question something else about TDD,
and we're simply failing to communicate your actual questions. I'll
put some words into your mouth, but to avoid attacking a strawman I
won't answer any of them until you claim one or more of them for your
1. Resolved: TDD does NOT result in (i.e. has no correlation to) good
2. Resolved: TDD costs more than other practices which have the same
or better code structure results.
I can answer either one of these; if you've been trying to communicate
something else, please speak up.
>>>Obtaining cohesive and loosely coupled is of course the holy grail
>>>software development. There is no doubt about it. I take it you
>>>to imply that the holy grail of software development is a benifit
You're replying to yourself and directly disagreeing. This is
something I haven't seen often on Usenet.
>But as you claim in your (dubious) analogy - it is hard to
>avoid obtaining good coupling and cohesion
I don't claim that; I don't make any claims about difficulty, or even
about good coupling and cohesion (except indirectly). I only claim
that a benefit is still a benefit even if there are other ways of
>>But more to the point: yes, I'm stating explicitly that TDD produces
>>cohesive and loosely coupled designs. I'm pretty sure I stated that
>>before, but I'm doing it again now. Lest I be mistaken for a
>>wild-eyed silver-bullet espousing maniac, though (who me?), let me
>>point out that I have some good company in making that claim: you.
>>claim that "much thought for architecture and/or design" can
>>result in cohesive and loosely coupled designs.
>>How much thought is unspecified. It has to be _much_, though.
>and how, pray tell, would that differ from any other approach to
>software. How many refactoring will be needed? etc
I can't tell you how much refactoring -- but I can tell you precisely
when the refactoring stops, and I can break the refactoring into small
chunks which are directly related to actual deliverables. Up-front
"thought", on the other hand, doesn't have any concrete tie to the
deliverable; you don't know how good your thought was until the
deliverable is ready.
>>>You have made a few assumptions here as to the nature of the
>>>initially produced code. Most important of which are:
>>>(1) Poor cohesion
>>>(2) Excessive coupling
>>>(3) Lack of observability (so that testing is relatively painless)
>>>To me that means the code was thrown together without much thought
>>>for architecture and/or design (ie spagetti or macaroni type code)
>>You asked me to gedankenexperiment without TDD; you didn't specify
>If you with to compare apples with sand, who am I to stop you from
No, I wish to compare apples with a lack of apples. If TDD gave no
benefits, then doing nothing would be as good as doing TDD.
Come on, this is FUNDAMENTAL. You can't do an experiment without a
>I am simply trying to indicate that - to convince others to adopt
>something (and it is all about adopting technology) that the benifit
>be a real benifit. Not some remarketing of something that is already
Your definition of "real benefit" should really be clarified. It seems
that you believe that nothing is beneficial if there's some other way
to gain the same result. This seems trivially false, as demonstrated
by my example of the benefits of a straightedge.
>>In that case, let me state the outcomes of this new experiment.
>>Terrible -- there'll be bugs in primitives, and debugging will
>>that I assume that the bug could be hiding /anywhere/, and normal
>>common sense won't serve as a reliable guide of when I can stop
>>testing (because I don't have any way of enumerating the tests I'll
>I take it you believe that above are consistent with appropriate
No, but they're consistent with untested cohesion and coupling.
Bug happen. They happen in cohesion and coupling as often, or MORE
often, than they happen in functionality (because programmers are
usually directly watching functionality, and often not really checking
cohesion and coupling thanks to at-the-time-reasonable assumptions).
>>I'll have made a number of false starts in design that an
>> elementary test would have revealed the uselessness of.
>Does that ever not occur?
Yes, when you've made the elementary test before you made the design,
and when you implemented the design before you went on to the next
step in design. In short, when you're doing TDD.
So you yourself have now identified something which you believe is a
good thing, and which no methodology that you know of can avoid; the
next step is to show that TDD can achieve that. If I can do that, this
debate is over.
>>will reveal some shortcomings in the observability of the design, so
>>I'll hack in some viewports to let my tests in, but each one will
>>require some more conditionally compiled code, and will increase the
>>number of different ways to build the software.
>How does all this differs from a need to refactor somehow?
In a sense it doesn't -- that's the brilliant thing about TDD. If you
need to refactor, do you want to discover the need while you have a
little bit of code which is all completely tested, or do you want to
discover the need after you have all the code, most of it untested?
>>>If you must assume the quality of the initial code which you write
>>>that poor, perhaps it should be rewritten/ refactored (depending
>>>your prefered buzz word) before you start testing.
>>How can I refactor code without tests? How can I assume the
>>testability is low if I haven't written any tests?
>The code transformation strategies are independent of the performance
Refactoring formally requires testing, to ensure that the change
doesn't disturb existing functionality. Refactoring informally is a
>You know the code is bad, and being an experienced developer you
>know the drill
You only find that the code is bad by attempting to test it.
Seriously, if I *knew* it was bad I wouldn't have written it.
>>Why, after all, did I wait this long before I started testing, when
>>could have written each test as soon as I saw the design point? If
>>done that, each design point would be tested already, and my design
>>would _have_ to be observable! If my design was tested with each
>>design point in isolation, then of course my design would be
>>decoupled. And if each design point had only enough code implemented
>>to merely pass its test, then each point is cohesive (although
>>refactoring this doesn't promise cohesion on any other scale).
My point, re-quoted.