unittest vs py.test?

[Roy Smith]

Peter Hansen  <peter at engcorp.com> wrote:
>It seems possible to me that I might have helped him
>solely by pointing out that unittest might not be so
>"heavy" as some people claimed.  I got the impression
>that he might be swayed by some unfounded claims not
>even to look further at unittest, which I felt would
>be a bad thing.

I'm the "him" referred to above.  I've been using unittest ever since
it was first added to the standard library (actually, now that I think
about it, I believe I may have been using it even before then).

And yes, I think unittest brings along a certain amount of baggage.
There is something attractive about having the same basic framework
work in many languages (PyUnit, JUnit, C++Unit, etc), but on the other
hand, it does add ballast.  I use it, I certainly don't hate it, but
on the other hand, there are enough things annoying about it that it's
worth investing the effort to explore alternatives.

>From the few days I've been playing with py.test, I think I like what
I see, but it's got other issues.  The "optimization elides assert"
issue we've been talking about is one.

It's also neat that I can write unittest-style test classes or go the
simplier route of just writing static test functions, but there's a
certain amount of TIMTOWTDI (did I spell that right?) smell to that.

I'm also finding the very terse default output from unittest (basicly
a bunch of dots followed by "all N tests passed") highly preferable to
py.test's verbosity.

In short, I haven't made up my mind yet, but I do appreciate the input
I've gotten.