Re: C++ fluency
On May 6, 5:08 pm, "Phlip" <phlip2...@gmail.com> wrote:
(And I am _really_ surprised these old-news threads are still
going. They are like "uses and abuses of Design Patterns" or
"how to throw exceptions". The 1990s lives on, huh?)
The more things change, the more they stay the same. Thorough
unit tests were a fundamental part of everyone's practice back
when compiling meant submitting a deck of cards in the evening,
and getting the results back the next morning. Somewhere along
the line, that practice got lost. Luckily, it's coming back.
I've always written the tests first, but then written at
least some minimal bit of code that should pass at least
some part of the tests before attempting to run the tests.
What's the point of running the test when you're sure
there's no possibility of even coming close to passing it at
all?
If you go in extremely tiny steps - one line of test, one line
of code - you are much more stable, and your tests penetrate
much deeper into the logic.
I suspect TDD was invented by people doing what you are doing,
but using the Smalltalk code browser. They discovered that run
the tests more often, over smaller changes, got easier. Then
they experienced a phenomenon I have since named "the head
eats the tail". They couldn't tell the difference between
writing the next test or the last code, and they were in fact
writing new tests and then passing them with new code. The
Smalltalk code browser apparently makes the One Test Button
technique very easy...
Note that there's only a very fine line between this and the
typical IDE attitude of writing something (anything), then
seeing what it does under the debugger, then "correcting" it,
iterating until you get something that "works". Of course, if
you're tests are as detailed as they should be, you don't need
the debugger, because the tests will suffice to indicate where
the problem is. But just writing random tests is no more
effective than just writing random code. Somewhere, up front,
some sort of thought (read "design") is required: what should
the code do.
--
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