This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Use specific asserts in collections tests
Type: enhancement Stage: patch review
Components: Tests Versions: Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: rhettinger, serhiy.storchaka
Priority: normal Keywords: easy, patch

Created on 2014-02-07 20:26 by serhiy.storchaka, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
collections_tests_asserts.patch serhiy.storchaka, 2014-02-14 10:35 review
Pull Requests
URL Status Linked Edit
PR 789 closed serhiy.storchaka, 2017-03-23 17:07
Messages (4)
msg210547 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-02-07 20:26
The proposed patch makes collections tests use more specific asserts. This will provide more useful failure report.
msg211195 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-02-14 02:03
The patch is missing.
msg211210 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-02-14 10:35
Oh, sorry. Here is a patch.
msg215423 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-04-03 05:33
Sorry, I don't think this makes the tests any better as all.  It is code churn for no benefit.

In our own code, the "more specific tests" risk hiding important details behind the abstraction (losing knowledge of what is actually tested).  For example, I don't like that assertIn actually does a "not in" test or that assertIsNot runs "is".  In those two cases, it doesn't make a difference but does hint at the loss of knowledge.

Also, changing tests carries a higher set of risks than changing other code because there are no tests-for-the-tests.  This means that it would easy to accidentally break a test from testing what it is supposed to and not know about it.

The "has a nicer error message" is a vacuous promise.  The new output:

    Traceback (most recent call last):
      File "/Users/raymond/Documents/tmp14.py", line 10, in test_one
        self.assertIs(a, b)
    AssertionError: a is not b

Isn't any better than the current output:

    Traceback (most recent call last):
      File "/Users/raymond/Documents/tmp14.py", line 13, in test_two
        self.assertTrue(a is b)
    AssertionError: False is not true

Both of them show a failing "is" test and the first one mysteriously outputs "is not" which is technically a different operator (albeit, unimportantly so).
History
Date User Action Args
2022-04-11 14:57:58adminsetgithub: 64749
2017-03-23 17:07:11serhiy.storchakasetpull_requests: + pull_request694
2014-04-03 05:33:30rhettingersetstatus: open -> closed
resolution: rejected
messages: + msg215423
2014-02-14 10:35:20serhiy.storchakasetfiles: + collections_tests_asserts.patch
keywords: + patch
messages: + msg211210
2014-02-14 02:03:02rhettingersetassignee: rhettinger
messages: + msg211195
2014-02-07 20:30:27serhiy.storchakalinkissue16510 dependencies
2014-02-07 20:26:56serhiy.storchakacreate