Scott David Daniels <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
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?
--
http://mail.python.org/mailman/listinfo/python-list
