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

[Michael Foord]

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 (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.
> _______________________________________________
> 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
>