[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

Gabriel Grant grantgm at mcmaster.ca
Wed Mar 19 08:24:49 CET 2008


Hi all,

This gem from unittest.py is pretty much the opposite of "one obvious way":

    # Synonyms for assertion methods

    assertEqual = assertEquals = failUnlessEqual

    assertNotEqual = assertNotEquals = failIfEqual

    assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual

    assertNotAlmostEqual = assertNotAlmostEquals = failIfAlmostEqual

    assertRaises = failUnlessRaises

    assert_ = assertTrue = failUnless

    assertFalse = failIf

Could these be removed for 3k?

There was a short discussion about this among some of those those
present in the Python Core sprint room at PyCon today and most
preferred the "assertEqual" form for [Not][Almost]Equal and Raises.

With assertFalse vs. failIf (and assertTrue vs. failUnless) there was
far less agreement. JUnit uses assertTrue exclusively, and most people
said they feel that using assertTrue would be more consistent, but
many (myself included) still think failUnless and failIf are much more
natural. Another issue with assertTrue is that it doesn't actually
test for 'True', strictly speaking, since it is based on equality, not
identity.

Its also interesting to note the original commit message:

> r34209 | purcell | 2003-09-22 06:08:12 -0500 (Mon, 22 Sep 2003)
> [...]
> - New assertTrue and assertFalse aliases for comfort of JUnit users
> [...]

assertEqual (and its cousins) were already present at that point.

In any case, if the decision is made to not use failUnless, something
still needs to be done with assert_ vs. assertTrue. assert_ seems
somewhat better to me, in that it has fewer characters, but I think
that a case could certainly be made to keep both of these.

I certainly don't have the authority to make a call on any of this,
but if someone else decides what colour to paint this bike shed, I can
try to get it done (hopefully with 2.6 warnings) tomorrow.

Cheers,

-Gabriel

P.S. If you were in the sprint room and feel terribly misrepresented,
please feel free to give me a swift kick both on-list and in person
tomorrow morning.


More information about the Python-Dev mailing list