Re: TDD: Test-Driven Design or Test-Driven Development?

From: Phlip (phlip_cpp_at_yahoo.com)
Date: 01/06/04 

Date: Tue, 06 Jan 2004 18:43:29 GMT

[Followups set to comp.software.extreme-programming]

Vladimir Levin wrote:

> I have a feeling that for some people, TDD stands for test-driven design.
> In other words, one doesn't need to think about a problem ahead of
> time. Instead, one starts by writing just one test.

TDD "says" that starting without an idea of the design is lower risk than in
other lifecycles. That, in turn, reduces the risk of starting with a bad
design idea, and conflating it.

> This test produces
> a bit of code. Then, the next test is followed by another piece of code.
> Eventually the correct implementation emerges organically from this
> process. Up to this point, I think this approach is perhaps a bit naive.

Your idea of TDD is a bit naive. But at this juncture "we" typically must
ask if you have tried it yet.

> I would argue for test-driven development: One can still think about a
> problem, doodle, do research, have a discussion with customers, write a
> mathematical proof for the correctness of an algorithm, etc. One is simply
> not allowed to write any code without first developing an automated test
> for it.

It started out called "test first design". That morphed to "test driven
design". Beck titled it "test driven development", in his first book about
it, because he envisioned all kinds of tests leading all of a project, at
all scales.

For example, don't doodle without some way to verify your doodle (per /Agile
Modeling/ by Scott Ambler). Don't research without some way to check you
are asking the right questions. Don't discuss things with customers without
an acceptance test framework to immediately and directly apply the
discussion to. Etc.

> Let's take a fairly straightforward example. An engineering application
> requires one to implement floating point calculations. It may be important
> for the software developer to do some leg work to understand how rounding
> should be done. This decision may affect how the calculations are coded.
> Should one use IEEE floating point numbers or binary coded decimals, for
> example? How many significant digits are needed? What kinds of numbers
> actually show up in these calculations in the engineer's day to day work?

For every ? you wrote, I see a test. It may or may not end up in the
production test suite, but automating that test would, at least, be fun.

Here's a project written test-first using trigonometry:

   http://flea.sf.net

When I rushed to its code, the tests told me I had to answer a few - but not
all - of your questions. (Answering all of them would have wasted time,
because I would have no test for "do you really need to test that
floating-point behavior in /this/ project?")

The tests told me that I needed a "fuzzy match", showing some output number
fell within a small range of a target. One should generally not compare
floating point numbers for exact equality. So my tests rapidly grew a
fixture called tolerance(). Next, the tests show that the arc-tangent of an
angle very close to 90 degrees flipped eerily between positive and negative
infinity, or something. So the tests grew more fixtures to check for
trigonometric tolerance.

Another great thing about the project was it proved that I could use TDD,
and some pre-existing code, to write an aggressively trigonometric program
without knowing anything about trig.

> Working out some of these details ahead of time sounds reasonable to me.
> However, I would say that before one writes any code for the calculation,
> one should write a series of tests that have been approved by the
> engineering team. That way, if the present design turns out to be flawed,
> hopefully the mistake can be caught and corrected right away. Also,
> if another programmer goes in to modify a calculation later, the test
> will hopefully catch any errors introduced by the modification.

Please describe the Test Driven Development process that you think we are
doing in more detail. You probably assume a "rush to code" or some such.
And novices reading the threads on these newsgroups would get a totally
distort idea of what's actually going on. But your last paragraph seems to
describe healthy team behaviors that TDD, among other Best Practices, seems
to encourage more than prevent.

Some folks code-and-fix. We tell them to test-and-code. Some folks saturate
their project with BDUF, making steering more expensive. We advise to not
fear rushing to code. Both of these advices distort what's actually going
on, because they address common industry problems without balance. 

-- 
  Phlip
   http://www.greencheese.org/InMildDefenseOfTheGnats
  --  DARE to resist drug-war profiteering  --

Relevant Pages

  • Re: Errors cancel sometimes
    ... I thought that it was remarkable, so I'm remarking on it. ... Goldberg's "What Every Computer Scientist Should Know About Floating ... elements of accurate numerical calculations on a computer as well. ... I'd be happy to have any pointers to more modern works that cover the ...
    (comp.programming)
  • Re: INT defect: Please try this on 2007 for me
    ... binary floating point representation and calculations. ... the low-order bits you should not be using Excel. ... as 40000.847999999 when formatted to 15 significant digits. ...
    (microsoft.public.excel.worksheet.functions)
  • Re: Have you guys ever noticed the void?
    ... >So fill the void yourself. ... learning to verify their calculations. ... against the design strengths. ... section to the members area to hold sets of design calcs. ...
    (rec.aviation.homebuilt)
  • Re: Have you guys ever noticed the void?
    ... > real idea of just where the strengths and weaknesses lie in a design? ... ACTUAL weight -- is a critical factor in those calculations. ... cracking a few books on airframe structural analysis, ...
    (rec.aviation.homebuilt)
  • Re: Program Computes incorrectly under VPC.
    ... >>owners of this software that it should not be used for floating point math. ... > NONE of the spreadsheets in the world today have EVER ... > calculations, ... > percentage of algorithms will fail in VPC. ...
    (microsoft.public.mac.virtualpc)