Data-driven testing

[Changjune Kim]

"Max M" <maxm at mxm.dk> wrote in message
news:X8Mpa.30197$y3.2398527 at news010.worldonline.dk...
> Peter Hansen wrote:
>
> > For throwaways, I don't write quite so many tests, and in many cases if
> > it's only a "small" throwaway script (e.g. one or two subroutines only,
> > plus a little mainline) I will write a test or two for the subroutines
> > (because I'm doing TDD, not because I want to have unit tests to make
> > sure my script works properly... if you see the distinction) but never
> > for the mainline.
>
>
> While I do understand the principles of tdd, testing first and all that,
> I have a hard seing why it should be an advantage to do it in the early
> stages of a project.
>
> Normaly if a am entering a new domain, where I don't have a clear
> picture of the requirements, I try out different approaches. Each
> approach using a different combination of ideology, objects and
functions.
>
> This is all to get a feel of the best approach in this particular
> domain. Some times I try out a *lot* of approaches before I end up with
> a particular elegant design.
>
> At which point I am ready to "solve the problem". It is at this point I
> can see the point of unit testing.
>
> In tdd do you really use testing for the first "creative" fase also?
>

In XP, they call that kind of exploration SpikeSolution. You can do SS with
or without TDD.

When I do TDD, I end up with a good design which I wouldn't have discovered
without TDD. Every time I do TDD I'm surprised at the final design. I
didn't expect the design. Moreover, it comes out with a different design
when TDD the same program slightly differently again. Often, it's more
creative than I am.

That said, I still do SS without TDD sometimes, but I love the explorative,
generative, and discovering power of TDD.