unittest vs py.test?

[Peter Hansen]

Raymond Hettinger wrote:
> BTW, the above code simplifies to:
> 
> from py.test import raises
> assert a == b
> raises(Error, func, args)

This is pretty, but I *want* my tests to be contained
in separate functions or methods.  The trivial amount
of extra overhead that unittest requires fits with
the way I want to write my tests, so it basically
represents zero overhead for me.

The above doesn't look like it would scale very
well to many tests in terms of maintaining some
semblance of structure and readability.

And once you add some functions or whatever to do
that, I'm still unclear on how the one or two lines
of extra code that unittest requires represents
an amount of code that really merits the label "heavy".

As for Roy's comments: I use a small internally
developed driver script which uses os.walk to find
all the files matching tests/*_unit.py or tests/story*.py
in all subfolders of the project, and which runs them
in separate processes to ensure none can pollute
the environment in which other tests run.  I can
dispense with the unittest.main() call, but I like
to be able to run the tests standalone.  I guess
with py.test I couldn't do that...

If py.test provides a driver utility that does
effectively this, well, that's nice for users.  If
it doesn't run them as separate processes, it wouldn't
suit me anyway.

Still, it sounds like it does have a strong following
of smart people: enough to make me want to take a
closer look at it to see what the fuss is about. :-)

-Peter