[Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)

Ben Finney ben+python at benfinney.id.au
Wed Jul 16 00:34:00 CEST 2008


"C. Titus Brown" <ctb at msu.edu> writes:

> On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote:
> -> I've been told by a couple of non-programmers that "failUnless"
> -> is more intuitive than "assert" if only for the reason that its
> -> unclear what "assert" might do. This is similar to one of the
> -> arguments raised in the PEP, but considered from the point of
> -> view of someone new to test frameworks it could be all the more
> -> important.
> 
> Maybe this is an unnecessarily hard line, but if someone doesn't know
> what "assert" does, then they should go look up the keyword -- it's
> part of Python (and present in C, C++, Perl, and PHP as well).  So
> unless the person is new to Python AND testing, they should know it.

That's exactly the problem with the 'assert*' names: The test methods
of TestCase *don't* do the same thing as the Python 'assert'
statement, and aren't meant to. The association is confusing, even
(especially?) if one knows what the 'assert' statement does.

> While I don't have a strong position on the assert* vs fail*, I
> think consistency and simplicity in test suites is at least as
> important as in code: if you have to work hard to understand and
> debug your test suites, you've done something seriously wrong in
> building your tests.

Yes. While I prefer the 'fail*' names, I would prefer to lose *either*
of 'assert*' or 'fail*' than to retain redundant names in the API.

-- 
 \     “If I had known what it would be like to have it all... I might |
  `\     have been willing to settle for less.” —Jane Wagner, via Lily |
_o__)                                                           Tomlin |
Ben Finney



More information about the Python-Dev mailing list