[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
jyasskin at gmail.com
Wed Mar 19 09:20:56 CET 2008
+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
> 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.
> 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
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
More information about the Python-Dev