[Zope-Checkins] CVS: Zope/lib/python/Products/Transience/tests - testTransientObjectContainer.py:1.14

[Tim Peters]

Update of /cvs-repository/Zope/lib/python/Products/Transience/tests
In directory cvs.zope.org:/tmp/cvs-serv17499/lib/python/Products/Transience/tests

Modified Files:
	testTransientObjectContainer.py 
Log Message:
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.


=== Zope/lib/python/Products/Transience/tests/testTransientObjectContainer.py 1.13 => 1.14 ===
--- Zope/lib/python/Products/Transience/tests/testTransientObjectContainer.py:1.13	Thu Jan 30 20:35:06 2003
+++ Zope/lib/python/Products/Transience/tests/testTransientObjectContainer.py	Thu May 15 11:21:53 2003
@@ -385,15 +385,15 @@
             assert self.t[x] == x + 1
 
     def testLen(self):
+        # This test must not time out else it will fail.
+        self.t._setTimeout(self.timeout)  # make timeout extremely unlikely
         added = {}
         r = range(10, 1010)
         for x in r:
             k = random.choice(r)
             self.t[k] = x
             added[k] = x
-        addl = added.keys()
-        addl.sort()
-        assert len(self.t) == len(addl), len(self.t)
+        self.assertEqual(len(self.t), len(added))
 
     def testResetWorks(self):
         self.t[10] = 1