unittest vs py.test?

[Roy Smith]

Scott David Daniels <Scott.Daniels at Acm.Org> wrote:
> Any code depending upon __debug__ being 0 won't be tested.  Sometimes
> test structures update values as a side-effect of tracking the debugging
> state.  Not massively likely, but it makes for a scary environment when
> your tests cannot be run on a non-debug version.
> 
> --Scott David Daniels
> Scott.Daniels at Acm.Org

What would happen if you defined

def verify (value):
   if not value:
      throw AssertionError

and then everyplace in your py.test suite where you would normally have 
done "assert foo", you now do "verify (foo)"?  A quick test shows that it 
appears to do the right thing.  I made a little test file:

------------------------------
#!/usr/bin/env python

def verify (value):
    if not value:
        raise AssertionError

class Test_foo:
    def test_one (self):
        assert 0

    def test_two (self):
        verify (0)
------------------------------

when I run that with "python py.test", I get two failures.  When I run it 
with "python -O py.test", I get one pass and one fail, which is what I 
expected to get if the assert gets optimized away.

The output is a little more verbose, since it shows the exception raised in 
verify(), but it gives you a stack dump, so it's not that hard to look one 
frame up and see where verify() was called from.

It's interesting that given the penchant for light-weight-ness in py.test, 
that the default output is so verbose (and, to my mind, confusing) compared 
to unittest.  I guess one could write their own output formatter and cut 
down on the verbosity?