[Python-Dev] PEP: Consolidating names and classes in the `unittest` module (updated 2008-07-15)
C. Titus Brown
ctb at msu.edu
Tue Jul 15 16:23:35 CEST 2008
On Tue, Jul 15, 2008 at 03:00:30PM +0100, Richard Thomas wrote:
-> On Tue, Jul 15, 2008 at 2:48 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
-> > So far I have "precedent and tradition" and "positive admonition looks
-> > better" in support of preferring the 'assert*' names. Are there any
-> > others?
->
-> 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.
-> On another note, while I understand that consistency is a good thing
-> is it really that important in test suites? Obviously the unittest
-> module itself should be internally consistent but why not provide
-> people using the all the synonyms they might want? I can see people
-> just wrapping TestCase to add the synonyms back in.
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.
Tests should be as simple as possible, and no simpler.
--titus
--
C. Titus Brown, ctb at msu.edu
More information about the Python-Dev
mailing list