unittest vs py.test?

[Michael Hudson]

Peter Hansen <peter at engcorp.com> writes:

> Raymond Hettinger wrote:
> > [Peter Hansen]
> > 
> >>This is pretty, but I *want* my tests to be contained
> >>in separate functions or methods.
> > In py.test, those would read:
> > def test1():
> >     assert a == b
> > def test2():
> >     raises(Error, func, args)
> > Enclosing classes are optional.
> 
> So basically py.test skips the import statement,
> near as I can tell, at the cost of requiring a
> utility to be installed in the PATH.
> 
> Where was all that weight that unittest supposedly
> has?

For PyPy we wanted to do some things that the designers of unittest
obviously hadn't expected[1], such as formatting tracebacks
differently.  This was pretty tedious to do[2], involving things like
accessing __variables, defining subclasses of certain classes,
defining subclasses of other classes so the previous subclasses would
actually get used, etc.  I've not programmed in Java, but I imagine
this is what it feels like all the time...

(Not to knock unittest too much, we did manage to get the
customizations we needed done, but it wasn't fun).

Cheers,
mwh

[1] this in itself is hardly a criticism: there are many special
    things about PyPy.
[2] *this* is the criticism.

-- 
  Well, you pretty much need Microsoft stuff to get misbehaviours
  bad enough to actually tear the time-space continuum.  Luckily 
  for you, MS Internet Explorer is available for Solaris.
                              -- Calle Dybedahl, alt.sysadmin.recovery