Unittests and external data....

[Peter Hansen]

Mike Meyer wrote:
> 
> While I'm really fond of unit tests, I keep running into problems of
> their needing more framework than can easily be captured in the
> unittest module.
> 
> For instance, I'm working on a project to interface a data source to
> an SQL database. Doing unit tests properly means I need to have
> multiple different versions of the source around, or I need to modify
> it on the fly. Neither of those is really very practical. 

Why do you think changing it on the fly is not "very practical"?  In
Python, it's eminently practical, and extremely easy and effective.
We do it all the time (not with SQL databases mind you, but with much
hairier beasts) and don't have a problem with it.

Multiple versions of source could be "practical", but it's a Very
Bad Idea as far as unit-testing and TDD go... far too high a risk
that you aren't testing the right thing, or that the manual maintenance
that's required will produce out-of-sync versions.  Don't go there. 

> Dealing with the SQL side of things is possible, so long as I start 
> with an empty database for the suite.

I recall a number of threads in the testdrivendevelopment mailing
list John Roth referred to which talked about just this point.  They
generally considered it the Right Thing to do to start with an empty
database.  The test setUp() would populate the database with the
necessary data and the test would run with it, then it would be
torn down for the next test.  If this is possible for you, why not
just go with what works?

> Anyone have any thoughts on how I might better deal with things like
> the source being external to the program?

The mock object suggestions are good as well, although it's always a
good idea to consider whether you can easily avoid them, for obvious
reasons.  If you go that route though, Python makes it so easy to do
that I'm still pleasantly surprised every time we do it...

-Peter