Re: [Pyunit-interest] comments on PyUnit

[Fred L. D. Jr. <fd...@ac...>]

Steve wrote:
 > There's no great harm in documenting the synonym 'failUnless()', since
 > 'assert_()' is slightly ugly.

Guido van Rossum writes:
 > (Which causes inconsistency and confusion, and got this whole thing
 > started.)

  Yes.  I propose that the Python Library Reference only document one
name for each method.  *Which* name should be decided here.
  This issue exists for the following pairs of names:

      failUnless  /  assert_
      assertEqual  / assertEquals
      assertNotEqual  / assertNotEquals

(Note that only one of these falls into the fail*()/assert*()
discussion!)

I wrote:
 >   - Guido suggests using a unique exception for test failures, similar
 >     to the use of TestFailed in the Python regression test.  This
 >     allows the test errors to be distinguished from the traditional
 >     use of "assert" in Python modules.  For backward compatibility it
 >     might be reasonable to subclass from AssertionError.

Steve:
 > That doesn't help backward compatibility, because the framework would still
 > have to catch 'AssertionError' in order to detect failures.

  I'm not sure I understand why -- do you *really* want to catch failures
from assert statements, or is there some other motivation?  I'd be
inclined to group AssertionError separately from some new exception
raised by test code.

Steve, in response to my comments on the exception to use:
 > As a slight simplification to the code, it makes sense. However, it would
 > never make sense for TestCase subclasses to change that (fail()) aspect of
 > their behaviour, since the framework strictly defines which exception is
 > considered a failure.

  But they way want to do additional things when fail() is called.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations