Commit 26ec18cd authored by Tim Peters's avatar Tim Peters

testLen(): This test implicitly relied on completing in less than 1

second of wall-clock time.  That's plenty, except when, e.g., a
burst of network activity takes the CPU away for a second.  Jeremy saw
it fail once yesterday when running Zope-2_6-branch pre-release tests,
and that was unfortunate timing <wink>.  I found that running it in a loop
eventually caused a spurious failure whenever I ran it too.

So, in just this test, boosted the timeout by a factor of 60.  This should
make it astronomically unlikely to fail.  Also sped the test by removing
unneeded .keys() and .sort() calls.  Also switched from using Python's
assert stmt to unittest's assertEqual() facility.
parent a6cfcc00
...@@ -385,15 +385,15 @@ class TestTransientObjectContainer(TestBase): ...@@ -385,15 +385,15 @@ class TestTransientObjectContainer(TestBase):
assert self.t[x] == x + 1 assert self.t[x] == x + 1
def testLen(self): def testLen(self):
# This test must not time out else it will fail.
self.t._setTimeout(self.timeout) # make timeout extremely unlikely
added = {} added = {}
r = range(10, 1010) r = range(10, 1010)
for x in r: for x in r:
k = random.choice(r) k = random.choice(r)
self.t[k] = x self.t[k] = x
added[k] = x added[k] = x
addl = added.keys() self.assertEqual(len(self.t), len(added))
addl.sort()
assert len(self.t) == len(addl), len(self.t)
def testResetWorks(self): def testResetWorks(self):
self.t[10] = 1 self.t[10] = 1
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment