Re: C++ fluency
On May 6, 10:51 pm, "Phlip" <phlip2...@gmail.com> wrote:
Andy Champ wrote:
TDD allows me to move on, incrementally, and know that what
I've written so far works.
That's a very dangerous assumption.
What he means is he and his teammates can safely ignore old
features while working on new features. Nothing more is
implied.
Now this was a trivially small change, and I defy anyone to
write a quick test to find it. Whenever I've told this
story to a TDD guru I've been told that real time is
different. Well, IMHO it isn't. All I've got there is
three independent threads - the disc, the app, and the
timer.
You are answering the frequently asked question "can TDD solve
hard problems like security, performance, concurrency,
reliability, traveling salesman, etc?". It cannot.
Thank you. Now that we're on the same page...
What it _can_ do, however, is enforce that you have
implemented an existing algorithm correctly. You TDD each of
its steps, without directly testing their efficiency or
reliability. You can then refactor the algorithm's code
together with the rest of the application without an excessive
concern for adding defects.
I thought that one of the D's in TDD stood for "design". What
you're describing, more or less, sounds like the benefits from
rigorous and frequent unit testing. Something that I've always
fought for. (It is important, of course, to realize 1) that the
testing isn't perfect---you need code review, formal proofs,
etc. in addition (NOT in place of) it, and 2) unit testing is
only as good as the tests it executes, so these must be reviewed
for completeness, etc., as well.)
That frees your time up for writing & running soak tests. You
will still have the occassional super-bug, and the occassional
one-month bug hunt. They will be super rare. I have heard that
teams switching to TDD (with, uh, Pair Programming) reported
10% of their previous defect rates.
That would be impressive. In the well run companies I've worked
in, the bug rate was generally less than 1 per 100 KLOC of code
going into integration. You're saying that TDD will give bug
rates of less than one error per million lines of code? (As far
as I know, only one or two organizations reach that. Without
TDD, but at very great cost.)
Incidentally we have an automated build and test process
where I work now. The build takes a little over an hour to
get the source out of source control and build right down to
the installer on a quad CORE-family Xeon; the automated
tests take about 8 hours on a farm of a dozen or so
machines, including the build box.
Ah, but when you change your code, you can test the current
module in <1 minute, and integrate from that, right?
When you change your code, you don't normally integrate the
results immediately anyway. You need good unit tests, which are
run as part of the check-in procedure (although this should be a
formality, since the coder will have already run them before
trying to check in), but even those don't have to be that fast.
(The coder may---probably will---want some faster and simpler
tests for his personal use, if he expects to have to run them
more than once.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34