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ée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34