"C. Titus Brown" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
