Deprecate assertEquals, assertNotEquals, assert_, assertAlmostEquals, assertNotAlmostEquals

[voidspace]

BPO	9424
Nosy	@rhettinger, @terryjreedy, @ezio-melotti, @merwok, @voidspace, @methane
Files	issue9424.diff: Patch to convert deprecated methods in the stdlib test suite issue9424-2.diff: Patch to add a DeprecationWarning to the deprecated assert* methods

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ezio-melotti'
closed_at = <Date 2010-11-25.21:58:35.139>
created_at = <Date 2010-07-30.00:05:51.003>
labels = []
title = 'Deprecate assertEquals, assertNotEquals, assert_, assertAlmostEquals, assertNotAlmostEquals'
updated_at = <Date 2020-07-02.06:18:45.376>
user = 'https://github.com/voidspace'

bugs.python.org fields:

activity = <Date 2020-07-02.06:18:45.376>
actor = 'methane'
assignee = 'ezio.melotti'
closed = True
closed_date = <Date 2010-11-25.21:58:35.139>
closer = 'ezio.melotti'
components = []
creation = <Date 2010-07-30.00:05:51.003>
creator = 'michael.foord'
dependencies = []
files = ['19677', '19755']
hgrepos = []
issue_num = 9424
keywords = ['patch']
message_count = 21.0
messages = ['112025', '113130', '113147', '113639', '113644', '113657', '113658', '113660', '113695', '115832', '121665', '121669', '121723', '121964', '121982', '122120', '122410', '122412', '132843', '132867', '372803']
nosy_count = 6.0
nosy_names = ['rhettinger', 'terry.reedy', 'ezio.melotti', 'eric.araujo', 'michael.foord', 'methane']
pr_nums = []
priority = 'low'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue9424'
versions = ['Python 3.2']

[voidspace]

Now that deprecations are silent by default it would be much less intrusive to deprecate unittest.TestCase.assertEqual

We have a persistent issue in the Python test suite of developers using assertEquals when we have standardised on assertEqual. In regrtest we could patch TestCase.assertEquals to raise a (hopefully helpful) error. That'll stop the blighters!

[terryjreedy]

What about the other duplicate pairs with a preferred choice?
Is there too much use of the deprecated choice?

[ezio-melotti]

If you are talking about assertNotEquals, assertAlmostEquals, and assertAlmostNotEquals they should go as well (I didn't even know they existed). assert_ is probably used more often, but I'd deprecate it too.
Note that in the 2.7 and 3.2 doc assert_ is already marked as deprecated, and the other methods are not documented.

The plan is:

1. replace all the occurrences of assertEquals, assertNotEquals, assertAlmostEquals, assertAlmostNotEquals, assert_ in the Python test suite with assertEqual, assertNotEqual, assertAlmostEqual, assertAlmostNotEqual, assertTrue;
2. deprecate assertEquals, assertNotEquals, assertAlmostEquals, assertAlmostNotEquals, assert_;
3. patch regrtest.py to raise an error when these methods are used, in order to avoid that they sneak in again in the Python test suite.

[rhettinger]

These synonyms have been around a very long time and many test suites have one or the other or both. Nothing good can come from breaking those existing test suites. We don't need to harm our users just to accommodate a stylistic preference.

[voidspace]

We aren't talking about *removing* these methods from unittest - but now that we have standardised on assertEqual for the Python test suite it is annoying (particularly for Ezio who changes) when *new* tests are checked in using the old (deprecated-but-not-actually-deprecated) methods.

As deprecation warnings are now silent by default deprecating these old methods would only affect developers who run their tests specifically looking for information like this. Making the change is also a single "search and replace" across a code-base, so not a difficult change.

Actually whether or not we deprecate these methods in unittest itself is one question (I'm only +0 on that - I don't really care if they live for ever in general and Raymond's response can be read as a strong +1 for that). What Ezio *really* wants is to have these methods raise errors if used during *regrtest* runs, so that core-Python developers no longer use them. That I am fine with - although we would need some way for the tests for these methods themselves to actually run.

[rhettinger]

What a tremendous waste of time and inane exercise. AFAICT, this is a zero value add.

Also, we try to avoid these sort of search-and-replace exercises because 1) they are not part of holistic refactoring (Guido's term for making changes while you're working on a particular module, not whole-sale sweep), 2) they risk getting it wrong and 3) it obfuscates the "svn ann" output making it more difficult to tell who did the original work.

The goal is of "have these methods raise errors if used during *regrtest* runs, so that core-Python developers no longer use them" is a worthless one. Raising errors for this sort of thing wastes the time of developers who are trying to get real work done.

-1

[ezio-melotti]

It's not really a waste of time, since it's just a find and replace and I already have a patch ready. I also believe that there are valid reasons to do it.

When I started learning about unittest, I clearly remember asking myself if I should have used "assertEqual" or "assertEquals" and thought that two different methods with two different names probably did two different things (TMBOOWTDI). I also remember thinking that "assertEquals" must have been a "plural" version of "assertEqual" able to accept more than two argument at once (i.e. assertEquals(a, b, c, d) -> a == b == c == d).

I can imagine people finding it in some code (possibly in the Python test suite), thinking that is a typo, being confused because the documentation doesn't mention it, wonder how the test can pass if they use a "ghost" method, asking themselves if the code is really executed and so on.

Since we are moving away from these methods, it's annoying seeing people using them and reintroduce them in the Python test suite and that wastes time during the commit reviews for the reviewer and for the committer that has to fix it and merge the fix.

This said, it could be enforced both in regrtest or with a commit hook.