Data-driven testing

[Aahz]

In article <X8Mpa.30197$y3.2398527 at news010.worldonline.dk>,
Max M  <maxm at mxm.dk> wrote:
>
>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?

That's another point I was getting at, yes.  But let me pretend I
actually know something about TDD (test-driven development, for
Googlers), and I'll try to answer your question:

When you're exploring solutions, how do you know that your solutions are
correct?  If your exploration phase keeps getting checked against your
evolving design document (as represented by unit tests), you know that
the solution you create actually works!

One thing I was particularly smug about was figuring out how to
implement my query "language" without a counter for tracking how many
search terms matched.  I'm not sure whether I would have figured that
out slower or faster with TDD.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?