Steve Howell wrote:
> --- Steven Bethard <[EMAIL PROTECTED]> wrote:
>> Have you tried py.test?
>>
>> http://codespeak.net/py/dist/test.html
>>
>> I've heard good things about it, but haven't gotten
>> around to trying it
>> yet. Here's a two-line test suite from the page
>> above:
>>
>> def test_answer():
>> assert 42 == 43
>>
>
> Changed the subject line.
>
> Nope, I haven't. I'm a tremendous advocate of unit
> testing, but I've never felt compelled to try out
> other libraries, because I work mostly on private code
> now, so the
> following-standard-practices-to-benefit-from-familiarity
> argument doesn't carry much weight with me, and also
> because I find it easy enough to do things on a
> roll-your-own basis. YMMV, of course.
My view is generally that if I can get someone else to maintain parts of
my code for me, that's a good thing. ;-)
> 1) For flat-out failures, we just fail with a
> traceback right away.
Looks like that's the -x/--exitfirst option in py.test.
> 2) We don't use assertions very often, but rather
> just diff the output files to the GOLD files. This
> may eventually stop to scale, but it hasn't yet.
I guess I don't do enough stuff with file input and file output for this
to make sense for me.
> 3)We have a little trickery to override imports,
> etc., as 99.99% of our code was never written with
> unit testing in mind, but I still want to regression
> test it.
>
> 4) We have quite a few mock-ish objects, mainly
> relating to simulating I/O situations.
You might look into the Python Mock module:
http://python-mock.sourceforge.net/
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
