unittest wart/bug for assertNotEqual

[Zac Burns]

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.

Python 2.6

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

 

[Mark Dickinson]

Using the assertNotEqual method of UnitTest (synonym for failIfEqual)
only checks if first == second, but does not include not (first !=
second)

It looks as though this is fixed in Python 2.7 (and also in 3.1):

http://svn.python.org/view?view=rev&revision=71032

 

[Steven D'Aprano]

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).)

 

[Zac Burns]

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).)

My preference would be that failIfEqual checks both != and ==. This is
practical, and would benefit almost all use cases. If "!=" isn't "not
==" (IEEE NaNs I hear is the only known use case) then those could
simply not use this method.

It would not surprise me if changing this would bring to light many
existing bugs.

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

 

[Steven D'Aprano]

My preference would be that failIfEqual checks both != and ==. This is
practical, and would benefit almost all use cases. If "!=" isn't "not
==" (IEEE NaNs I hear is the only known use case)

numpy uses == and != as element-wise operators:

import numpy
a = numpy.array([10, 20, 30, 40])
b = numpy.array([10, 20, 31, 40])
a==b array([ True, True, False, True], dtype=bool)
a!=b array([False, False, True, False], dtype=bool)
not a!=b

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()

then those could simply not use this method.

I'm not so sure this is a good idea. Python specifically treats == and !=
as independent. There's no reason to think that a class must have both,
or that it's an error if it defines == without !=, or even that they are
reflections of each other. numpy doesn't, and that's a pretty huge
counter-example.

It would not surprise me if changing this would bring to light many
existing bugs.

It would surprise me.

 

[Ethan Furman]

My preference would be that failIfEqual checks both != and ==. This is
practical, and would benefit almost all use cases. If "!=" isn't "not
==" (IEEE NaNs I hear is the only known use case)

numpy uses == and != as element-wise operators:

import numpy
a = numpy.array([10, 20, 30, 40])
b = numpy.array([10, 20, 31, 40])
a==b

array([ True, True, False, True], dtype=bool)

array([False, False, True, False], dtype=bool)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()

then those could simply not use this method.

I'm not so sure this is a good idea. Python specifically treats == and !=
as independent. There's no reason to think that a class must have both,
or that it's an error if it defines == without !=, or even that they are
reflections of each other. numpy doesn't, and that's a pretty huge
counter-example.

It would not surprise me if changing this would bring to light many
existing bugs.

It would surprise me.

Two issues: 1) Sounds like we should have two more Asserts --
failIfNotEqual, and assertNotNotEqual to handle the dichotomy in Python;
and 2) Does this mean (looking at Mark Dickinson's post) that 2.7 and
3.1 are now broken?

~Ethan~

 

[Gabriel Genellina]

Two issues: 1) Sounds like we should have two more Asserts --
failIfNotEqual, and assertNotNotEqual to handle the dichotomy in Python;
and 2) Does this mean (looking at Mark Dickinson's post) that 2.7 and
3.1 are now broken?

1) assertEqual and assertNotEqual test for == and != respectively. The
failXXX methods are being deprecated. Why do you think we need more
asserts?
2) Not exactly, but there are still inconsistencies (e.g. assertDictEqual
and assertMultiLineEqual use != instead of ==, and some assertion messages
use the wrong terminology)

 

[Ethan Furman]

1) assertEqual and assertNotEqual test for == and != respectively. The
failXXX methods are being deprecated. Why do you think we need more
asserts?

Ignorance, of course. I didn't know those were there. Hopefully
the OP will also now realize those are there.