Logged In: YES
user_id=80475
Matthew, thanks for the patch. It gets a little better with
each update (though it is still in dire need of a spell-check).
The cost/benefit of adding this to the unittest module is not
clear. Perhaps, it would be worthwhile to present it on the
newsgroup to tease out the idea, build a fan club for it, or
come up with a simpler API.
My biggest issue with the unittest module is that it is already
too extensive. One has to read a small book on the subject
to get started. The number of doc pages, classes, and
methods rank it as more complex than most of the net
modules (with the notable exception of the email package).
In Beck's TDD book (p. 119), he comments that some
unittest packages are already too complicated for his tastes.
This patch would make the complexity issue worse. It takes
longer to figure out how the use the patch that it does to
create a small, easy-to-read, special purpose mock object.
Also, I'm concerned that MockObjects tend to create a false
sense of security in a situation where the actual object
behavior diverges from the simulated behavior. Also, to the
extent that a simulation is simple, it tends to discourage
adding tests that exercise all the nuances of a real object.
For example, a MockDatabase may simulate the expected
replies to some queries but doesn't behave enough like the
real thing to encourge tests on commits, rollbacks, cache
flushing, re-ordered tables, etc.
If this doesn't get added to the unittest module, it would
certainly be worthwhile to post it to the Python Cookbook so
that advanced users can get to it when they need it.
|