test_numdict fails: repr is not sorted #2736

Closed
opened 2016-02-23 06:24:25 +00:00 by warner · 2 comments

While setting up a windows unit test machine on Appveyor (#2344), I saw a consistent unit test failure:

[FAIL] 
Traceback (most recent call last):
  File "C:\projects\tahoe-lafs\.tox\py\lib\site-packages\allmydata\test\test_util.py", line 1356, in test_numdict
    self.failUnlessEqual(repr(d), "{'a': 1, 'b': 2}")
  File "C:\projects\tahoe-lafs\.tox\py\lib\site-packages\twisted\trial\_synctest.py", line 437, in assertEqual
    super(_Assertions, self).assertEqual(first, second, msg)
  File "C:\Python27-x64\Lib\unittest\case.py", line 513, in assertEqual
    assertion_func(first, second, msg=msg)
  File "C:\Python27-x64\Lib\unittest\case.py", line 506, in _baseAssertEqual
    raise self.failureException(msg)
twisted.trial.unittest.FailTest: "{'b': 2, 'a': 1}" != "{'a': 1, 'b': 2}"
 
allmydata.test.test_util.DictUtil.test_numdict

It looks like this test is inappropriately requiring that the repr of a dictutil.NumDict is sorted, when the implementation delegates *repr* directly to the underlying (normal) dictionary, which of course makes no guarantees about ordering.

I think that assertion should just be deleted, but maybe you want to change the implementation to provide a stable repr instead. Or maybe we should delete NumDict.. it only appears to be used in one obscure logging tool.

While setting up a windows unit test machine on Appveyor (#2344), I saw a consistent unit test failure: ``` [FAIL] Traceback (most recent call last): File "C:\projects\tahoe-lafs\.tox\py\lib\site-packages\allmydata\test\test_util.py", line 1356, in test_numdict self.failUnlessEqual(repr(d), "{'a': 1, 'b': 2}") File "C:\projects\tahoe-lafs\.tox\py\lib\site-packages\twisted\trial\_synctest.py", line 437, in assertEqual super(_Assertions, self).assertEqual(first, second, msg) File "C:\Python27-x64\Lib\unittest\case.py", line 513, in assertEqual assertion_func(first, second, msg=msg) File "C:\Python27-x64\Lib\unittest\case.py", line 506, in _baseAssertEqual raise self.failureException(msg) twisted.trial.unittest.FailTest: "{'b': 2, 'a': 1}" != "{'a': 1, 'b': 2}" allmydata.test.test_util.DictUtil.test_numdict ``` It looks like this test is inappropriately requiring that the repr of a `dictutil.NumDict` is sorted, when the implementation delegates `*repr*` directly to the underlying (normal) dictionary, which of course makes no guarantees about ordering. I think that assertion should just be deleted, but maybe you want to change the implementation to provide a stable repr instead. Or maybe we should delete `NumDict`.. it only appears to be used in one obscure logging tool.
warner added the
code
normal
defect
1.10.2
labels 2016-02-23 06:24:25 +00:00
warner added this to the undecided milestone 2016-02-23 06:24:25 +00:00
Brian Warner <warner@lothar.com> commented 2016-02-23 18:52:17 +00:00
Owner

In 28f2a0f/trunk:

test_util: tolerate unordered repr of NumDict

NumDict does not make any claims about the order of its repr(), so the
test needs to be prepared for it to be stringified in any order. On unix
the old test happened to pass, but on certain windows boxes (maybe
certain versions of python?), it failed. Fixes ticket:2736.
In [28f2a0f/trunk](/tahoe-lafs/trac-2024-07-25/commit/28f2a0f12dfa59deb403609dcb5fc6eef58e8e7b): ``` test_util: tolerate unordered repr of NumDict NumDict does not make any claims about the order of its repr(), so the test needs to be prepared for it to be stringified in any order. On unix the old test happened to pass, but on certain windows boxes (maybe certain versions of python?), it failed. Fixes ticket:2736. ```
tahoe-lafs added the
fixed
label 2016-02-23 18:52:17 +00:00
Author

Milestone renamed

Milestone renamed
warner added this to the 1.11.0 milestone 2016-03-22 05:03:36 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2736
No description provided.