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

Wed Mar 19 17:37:37 CET 2008

Gabriel Grant wrote:
> 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.
>
+1 on standardising on 'assert*' and removing 'fail*'.
+1 on making 'assertTrue' test for True rather than any non-false object 
(and vice versa for assertFalse)
For migration a simple subclass of TestCase that provides the old 
methods/semantics is trivial to write. No need for monkey-patching.
Michael Foord
> Its also interesting to note the original commit message:
>>>> r34209 | purcell | 2003年09月22日 06:08:12 -0500 (2003年9月22日)
>> [...]
>> - 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.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>