unittest wart/bug for assertNotEqual

Steven D'Aprano steven at REMOVE.THIS.cybersource.com.au
Tue Oct 20 23:29:22 CEST 2009

On Tue, 20 Oct 2009 10:20:54 -0700, Zac Burns wrote:

> Using the assertNotEqual method of UnitTest (synonym for failIfEqual)
> only checks if first == second, but does not include not (first !=
> second)
> According to the docs:
> http://docs.python.org/reference/datamodel.html#specialnames There are
> no implied relationships among the comparison operators. The truth of
> x==y does not imply that x!=y is false
> The name assertNotEqual to me implies a check using !=. This misleading
> title can cause a programmer to think a test suite is complete, even if
> __ne__ is not define - a common mistake worth testing for.

I was with you right up to the last six words.

Whether it's worth changing assertNotEqual to be something other than an 
alias of failIfEqual is an interesting question. Currently all the 
assert* and fail* variants are aliases of each other, which is easy to 
learn. This would introduce a broken symmetry, where assertNotEqual tests 
something different from failIfEqual, and would mean users have to learn 
which assert* methods are aliases of fail* methods, and which are not. 
I'm not sure that's a good idea.

After all, the documentation is clear on what it does:

     |  assertNotEqual = failIfEqual(self, first, second, msg=None)
     |      Fail if the two objects are equal as determined by the '=='
     |      operator.

(Taken from help(unittest).)


More information about the Python-list mailing list