Data-driven testing

[Changjune Kim]

Hi, Aahz.

"Aahz" <aahz at pythoncraft.com> wrote in message
news:b867d7$f53$1 at panix2.panix.com...
> As I just mentioned in another post, I'm writing an ASCII database for
> my address book.  Actually, the main reason for writing it was because
> I've been maintaining multiple lists for various kinds of party invites,
> and the update problem was killing me.
>
> While writing it, it occurred to me that I *ought* to be using unit
> tests to make sure that it was working correctly, but two things stopped
> me.  Secondly, I was in a hurry.

On the second:

KentBeck : "If you write automated tests, you'll get more done every day."
Johnny : "But we have too much to do. We don't have time to write tests."
KentBeck : "No, no. You didn't understand. You'll get _more_ done, not
less."
Johnny : "Yes, but we don't have time for testing."

>
> But firstly, I ran into the same problem I had when writing the BCD
> module: how the heck does one write tests when the results are
> hand-calculated?  There were several times when I wrote what I thought
> were correct tests for the BCD module, and my code was right and my test
> was wrong.
>
> In the case of my ASCII database, I'm going to need a big matrix to
> properly test the query language.  How do I build that matrix?

You make tests in order to increase confidence. If you lose any confidence
writing tests, find another way. One option is to divide and conquer. Don't
try to compare the (initial input, final output) pairs at the first step.
Start from the parts; it's called _unit_ testing.

For example, if your program caculates a polynomial expression like
x^2+2x-1 and you are afraid your hand-calculated value is wrong, test
squaring and adding, substracting first, for instace. Now you have one step
further. Try unittesting step by step. If you have some time :) have a look
at TDDBE by Kent Beck.


With warmest regards,

June Kim