Data-driven testing

[Peter Hansen]

Max M wrote:
> 
> 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.

I think you're leading us in a new direction.  Aahz asked about "throwaway
scripts", and to me that has the meaning of "a script with a very clear
and specific but short-lived purpose".  In other words, about the farthest
thing from "early stages of a project" that you could imagine.  There is
no project: there is a little script, then nothing.  Maybe calling them
nihilistic scripts would be better. :-)

> 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.

Agreed.  As others have pointed out, XP calls this a Spike Solution
(picture driving a spike all the way through the problem in the most 
expedient, ugliest manner possible, to explore it, but with no intention
of using that as a the real solution).  Maybe Exploratory Surgery would
be another good view of it.

> 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?

Nope, other than, as I said elsewhere in this thread, when I have very
clear ideas about a specific "unit" of code that I want to include even
in my spike, in which case I may well write it test-first in order to
have some confidence that it will work at all.  Failing to do that would
mean a higher likelihood of going down the wrong path, or spending way
too long on a fruitless candidate solution, because my code isn't doing
what I think it's doing.

The XP/TDD view of all this would be like this: "Initially, write tests 
for *everything*.  When you learn when you don't need to write tests
for something, don't do it.  When you realize you made a mistake in not
writing a test, back up a little and slow down, writing tests again 
until you're back on track."

-Peter