unittest wart/bug for assertNotEqual
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 !=
> 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 '=='
(Taken from help(unittest).)
More information about the Python-list