Re: TDD: Test-Driven Design or Test-Driven Development?
From: Phlip (phlip_cpp_at_yahoo.com)
Date: 03/01/04
- Next message: Robert C. Martin: "Re: PPP Payroll Example"
- Previous message: Laurent Bossavit: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- In reply to: Nick Landsberg: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Next in thread: Nick Landsberg: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Reply: Nick Landsberg: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 01 Mar 2004 05:46:03 GMT
Nick Landsberg wrote:
> I did not mean to cause friction. I am trying to understand
> your points. Bear with me, please.
You are allowed to cause friction on USENET - that's what it's for.
I meant you had not yet learned the TDD cycle, and this caused you friction
for your own understanding of related details.
> Quite honestly, that tutorial just illustrates the
> steps a reasonably competent developer would to
> through to write the given function. It is a normal
> part of development. I code this, test to see that it
> works.. I code a little more, etc, etc.
You still said it backwards. "I code this, test to see that it works".
There is simply no way to understate the ramifications of the simple act of
designing by writing tests first. There are many ways to analyze it, and
many ways to feel it (such as trying a simple experiment for yourself), but
ultimately it is a sea-change in the history of programming. But one can't
learn it by gain-saying individual statements on USENET, without their
context.
> They spend hardly any time running a debugger because
> our experience has been that humans are better at
> finding bugs than machines.
The TDD cycle is very good at preventing bugs, and making the few that slip
thru easier to find. These, it augments human's ability to find bugs.
But I meant using the debugger to seek the source of a known bug. I don't
know about real-time land, but in business or science apps, without TDD,
even with a planned design process, each bug report causes a long session
with a debugger to find the root cause.
> > A poster to another newsgroup read my tutorial and stated I should have
> Should have what?
Sorry - that I should have implemented each of a list of requirements, such
as "can't have more than three of the same letters in a row", or "M is
always to the left of L". I should not do the roman numerals example in that
order, because the requirements don't progress from simplicity. Starting
with "I", then going to "II", permits the advanced requirements to "already
work", because they have no opportunity to fail yet.
> In the bean-counter world in which I live, I'm sorry
> to say, it this methodology was mandated, it would
> also be mandated that every developer should document
> that they had performed these test and what they
> were and what were the results. This would take much
> more time than performing the tests (which are what any
> developer does anyway, nothing new), and, because of the overhead
> of reporting that they had performed these tests,
> slow down the development process. Sorry, but
> I'm not convinced at this point.
Stop calling them "tests". The things called "tests" that you are familiar
with appear downstream of the design process.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces
- Next message: Robert C. Martin: "Re: PPP Payroll Example"
- Previous message: Laurent Bossavit: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- In reply to: Nick Landsberg: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Next in thread: Nick Landsberg: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Reply: Nick Landsberg: "Re: TDD: Test-Driven Design or Test-Driven Development?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
