Re: c++ class design: where to put debug purpose utility class?
On Jun 29, 4:10 pm, "Phlip" <phlip2...@gmail.com> wrote:
1230987za wrote:
But I think there is a subtle difference to define "unit". I
can not agree with James Kanze more on unit test *when* the
unit is a class, but how about the unit is a function? A
class' public function?
I am adapting Test Driven Development, TDD, into my daily
programming.
Kanze is a classically-trained "unit tester". In some circles
"unit" is a QA concept - specifically, if a test fails, you
only need to inspect one unit.
You mean I'm using a word in its standardly accepted meaning.
(Unit tests have been a required part of development for many,
many years now.)
So "units" are "things which are clearly delimited and
accessible to inspection".
That's more or less a definition of "unit", yes. In practice,
units are units---they're more or less the lowest level in a
hierarchial development.
That should map onto C++ classes -
Why? That's the first time I've heard that. (There are a lot
of cases where they do map onto C++ classes.)
specifically due to overlapping requirements. C++ classes
_should_ be "things which are clearly delimited and accessible
to inspection". Yet sometimes, by necessity, the "unit" is a
translation unit, or a header, or a peculiar include file, or
a global constant.
As a minimum, a "unit" is never less than a translation unit,
since current technology doesn't allow you to break things down
any finer. (Of course, a translation unit is often less than a
complete class.)
Under TDD, if a test fails during development, you only need
to inspect (or revert) the most recent edit.
I'm sorry, but that's bullshit. Regardless of the design
philosophy, if you have halfway decent unit tests, there is a
high probability that the error is somehow due to the most
recent edit. And regardless of the design philosophy, there's
always a small chance that something in the recent change has
triggered an error which was already there before. (That's one
of the meanings of undefined behavior---and TDD doesn't remove
undefined behavior from the language.)
So Developer Tests and Unit Tests have overlapping abilities
and motivations. Many TDD tests will also allow you to isolate
faults to a small unit.
All unit tests allow you to more or less isolate faults to a
small unit. None are perfect, however.
Please bear with me, I am doing-it-before-learning-it. I
designed my class interface, without implementing the API
functions, I started designing my test class to test each
API function. It is at this point my question coming up.
That's not really TDD. You start at the test, and write each
test case to illustrate one aspect of your target class.
Which, of course, isn't true, because until you have at least
some idea as to what the class is to do, you can't write the
tests. You start by determining what the class is to do (in
most cases, that means some high level design). You don't start
by just typing in code, whether it is a test or anything else.
(I find it very hard to conceive that in this day and age,
people are still suggesting that we code before we think. And
proposing it as a silver bullet, no less.)
--
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