unittest vs py.test?

[Roy Smith]

Peter Hansen <peter at engcorp.com> wrote:
> unittest can really be rather light.  Most of our
> test cases are variations on the following, with
> primarily application-specific code added rather than
> boilerplate or other unittest-related stuff:
> 
> import unittest
> 
> class TestCase(unittest.TestCase):
>      def test01(self):
>          '''some test....'''
>          self.assertEquals(a, b)

Well, right there the "extra" stuff you needed to do (vs. py.test) was 
import unittest, inherit from it, and do "self.assertEquals" instead of 
just plain assert.  But (see below), that's not the big thing that attracts 
me to py.test.

> I'm a little puzzled why folks so often consider this
> particularly "heavy".  No need to deal with suites,
> TestResult objects, etc, as others have suggested,
> unless you are trying to extend it in some special
> way.

In all but the most trivial project, you're going to have lots of tests.  
Typically, each class (or small set of closely related classes) will go in 
one source file, with a corresponding test file.  You'll probably have 
stuff scattered about a number of different directories too.  That means 
you need to build some infrastructure to find and run all those various 
tests.

One way would be futzing with suites (which I still haven't completely 
figured out).  Another way would be building a hierarchical series of 
dependencies in Make (or whatever build tool you use) to run your tests.  
The latter is what I usually do.  The idea that I can just type "python 
py.test" at the top level and have it find and run everything for me just 
blows me away convenience-wise.

I also like the idea that I just stick print statements into my tests and 
the output automagically goes away unless the test fails.  I'm a firm 
believer that unit tests should NOT PRODUCE ANY OUTPUT unless they fail.  
I'm working with a system now where the unit tests not only produce reams 
of output, but it's also rigged to keep going in the face of failure.  
Trying to find the actual error in the output is a nightmare.