Re: Test Driven Development
From: Universe (universe.covad.com)
Date: Wed, 10 Dec 2003 03:16:11 -0500
"Ron Jeffries" <ronjeffries@REMOVEacm.org> wrote in message
> On Tue, 9 Dec 2003 13:18:40 -0500, "Universe" <email@example.com>
> >At times they may do DbC as part of TDD, but most of TDD is simple
> >testing to see if *any* line of code compiles!
> No, it is not. Writing a test does not help to make sure that the
> compiles. It helps to make sure that it runs. This is a rather
How? In what way. How does the 10 seconds where I read that you
understand you got the green and then move on to write the code you
already had in mind the code differ if one is only checking for
compilation and not that it runs. What would be different?
> >And it is this kind of prosaic code testing that is presented by the
> >xp'ers as integral to TDD. Most of the time when they illustrate
> >they code what is in their mind, test to see if it "gets the green",
> >attempt to fix if it doesn't "get the green", or of it does, then
> >code more of what is in their mind, and so on.
> That's not the best way. If the test doesn't go green on the first
> probably better form to throw the code away and write it again rather
> it, unless one sees the problem immediately. This is a minor but not
OK, but my overall point remains. You clarify that point, yet don't
deal with what I say about you all writing what's in your mind, testing
it and then writing more of what was in your mind. The testing doesn't
push or pull in terms of conceptually organizing code. Whatever you
write is what you had in mind. If A fails, at most you then write B
that you already had thought about. And simply changing code to another
structure you had in mind based solely upon interpreter/complie error
makes the exercize outsized in irrationality. You specify no basis for
what would cause you to look for a missing semi, or not looking. And
enlarge this to all other just syntax errors that may occur. How does
code line design thinking weigh in and trade-off against 1) simple, or
2) large syntax error.
I mean this mkes absolutely no sane sense. It may have just been a
missing brace or semi. How would you judge that you ought to look for a
syntax error, not look, no it's synatx, but write new code anyway,
distiguish syntax from logical error, do you try that?, on and on,
> >I see nothing in this that shows how the testing is taking them some
> >where. The design in their mind is really what's driving code
> >code design. The test simply verifies that such code compiles.
> No again. The tests verify that the code runs, not that it compiles.
> I agree that the (evolving) design in our mind is what's driving code
> which Is why I take issue with other claims of yours that we are "just
You forget that I define the essence of hacking as piecemeal,
non-holistic based activity. From reading, it seems most others writing
in industry books, and periodicals have a similarm sense of hackery.