[Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses
Jeffrey Yasskin
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
> identity.
>> 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/jyasskin%40gmail.com
>
--
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/
More information about the Python-Dev
mailing list