James Kanze wrote:
> On Jun 29, 4:10 pm, "Phlip" <phlip2...@gmail.com> wrote:
>
>> 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.)
>
Um, we agree again!

>
>> 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.
>
Here's where we differ. The above assumes you have a design which
defines your classes.

Often with TDD, you test and to code to a more abstract requirement and
the design (classes) follow the tests. Sometimes there's an agreed
interface, or a base class that is being extended, but often the tests
are testing an action for a reaction.

I've just been looking back through some of my tests and just about all
of my JavaScript tests are testing reaction to events and in one large
C++ project most of the tests test systems states. Set a threshold,
change something, look for the reaction.

Coupling tests too closely to classes makes refactoring much harder.

> (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.)
>
I don't think anyone is suggesting that. What is being suggested is a
different way of thinking.

--
Ian Collins.