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

[Jeffrey Yasskin]

+1 to assert* from me. the fail* variants always feel like
double-negatives. I also always use assertTrue instead of assert_. But
I don't care enough to argue about it. :)

On Wed, Mar 19, 2008 at 2:24 AM, Gabriel Grant <grantgm at mcmaster.ca> 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.
>
>  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/jyasskin%40gmail.com
>



-- 
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/