PSP, XP, TDD and other methodologies for solitary programmers

Peter Hansen peter at engcorp.com
Thu Jan 2 19:15:15 EST 2003


Brad Clements wrote:
> 
> I guess there's no getting around actually looking at the database after
> storing an object..

I would suggest *not* "looking at the database", if by that you mean
actually examining it through means other than its regular interface.
If it's a SQL database, execute more SQL statements to retrieve the
info.  If, in fact, you are using it through some serialization methods
to store your objects, then execute the reverse of those methods
and compare the restored objects with the ones prior to the save.
Always try to test behaviour (in this case, save and restore), not 
data (such as the format of the data in the database, unless you 
are actually writing the database yourself).

> Speaking of TestCase, I though that setUp would be called only once for all
> test* included in the class, but I find that setUp() is called for ever test
> case in the same class.

That's definitely true, by design.  In most cases, you want to begin
each test anew, with completely fresh data.  Tests should almost never
depend on the execution of previous tests, or you will get into deep
trouble.

> What I want is one instance of the TestCase to be created (hence, one call
> to setUp()), then each test* case to be run in that TestCase instance.

Option: make setUp() and tearDown() empty or trivial, and put the real
setup in some module-level function that is executed only once at startup.

Alternative: have only a single test() method in the TestCase, and 
from it call a series of other functions (e.g. _test01(), _test02())
which actually do your testing.

> I guess I'll need to make up something to do it that way, since setting up a
> temporary database table for every test in my suite will be expensive.

That is one good reason to break the "almost never" rule I mentioned above.

XP proponents might say "make the setup less expensive".  Maybe there
are some approaches you can take which will lead to that, like running
most of the tests from a "checkpointed" version of the database which
you save during an earlier test.

-Peter




More information about the Python-list mailing list