unit testing

[Steven Bethard]

Steve Howell wrote:
> --- Steven Bethard <steven.bethard at gmail.com> 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