On 4/19/02 11:34 AM, "Chuck Esterbrook" <[EMAIL PROTECTED]> wrote:
>> (2) The default exception raised by PyUnit is AssertionError, and I >> used to see (and write) many unit tests using the 'assert' statement. >> I've seen a few debates, primarily stemming from the PythonLabs >> group, about whether this is right, and I've been convinced that it >> isn't - if an assertion fails inside of tested code, you want to >> isolate that from normal test failures. Fortunately, PyUnit (at > > I've heard this before but keep missing the explanation of why an > "assert" in the code has to be separated from an assert in the unit > test. I've been using asserts in my unit tests for quite awhile and > never experienced any headaches. > > Do you have any insights into that? I'll quote Tim Peters response to me when I first asked the question:: > Running with -O can easily trigger new program logic errors (for example, a > variable initialized only in an "if __debug__:" block). So, if you're going > to release code intended to be run using -O, you're not testing it as it's > intended to be used unless you test it with -O too. Testing code in ways > it's not intended to be used is the odder exercise of the two <wink>. > > For this reason, all uses of "assert" were purged from Python's test suite > some time ago, and, yes, since then, some tests have failed only under -O, > some only without -O, and some both ways. We're happy to find bugs any way > we can get them, and running a test suite is the easiest way there is. The thread starts here: http://lists.zope.org/pipermail/zope-coders/2001-October/000238.html Even if assertions get separated from the -O option, using the 'assertXXX' or 'failUnlessXXX' unit test methods often produce better default error/failure messages. Furthermore, if you want to test that an application assertion is doing the right job in a unit test, how do you test it? def somemethod(self, num): assert type(num) is type(1.0) # assert it's a float return num + 3.3 self.failUnlessRaises(AssertionError, somemethod, 42) The above would raise an AssertionError if somemethod *didn't* raise an AssertionError, which can lead to a little brain meltdown. Furthermore, if you were just testing this: self.failUnlessEqual(somemethod(42), 43.3) Or, also: assert somemethod(42) == 43.3 It would raise an AssertionError, which PyUnit assumes as a unit test failure. But the AssertionError isn't being raised as a result of the 'failUnlessEqual' unit test statement, it's being raised inside of the 'somemethod' body. So, there's a potential for further confusion. You'd get a report of a test Failure, but it's not the failure you're looking for. It's not a horrendous situation, but it can lead to some testing confusion. -- Jeffrey P Shell www.cuemedia.com _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
