Issue #729
closedPulp tests should not rely on wall clock time
Description
There are several areas where Pulp test rely on wall clock time. Below is a quick list of known ones we have encountered, but there may be more.
In TestScheduledCallCalculateTimes, there are two tests that rely on the test taking less than 1 second to run: test_now and test_first_run_now. These tests will randomly fail if the test runner is slow.
Also in this test class: unit.server.db.model.test_dispatch.TestScheduledCallInit
Traceback (most recent call last):
File "/usr/lib64/python2.7/unittest/case.py", line 367, in run
testMethod()
File "/home/jenkins/workspace/unittest-pulp-pr/node-type/f21-np/pulp/server/test/unit/server/db/model/test_dispatch.py", line 352, in test_no_first_run
self.assertTrue(abs(now - first_run) < timedelta(seconds=1))
File "/usr/lib64/python2.7/unittest/case.py", line 460, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true
Also in unit.server.managers.schedule.test_utils.TestUpdate.test_update
======================================================================
FAIL: test_update (unit.server.managers.schedule.test_utils.TestUpdate)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/mock.py", line 1224, in patched
return func(*args, **keywargs)
File "/home/rbarlow/devel/pulp/server/test/unit/server/managers/schedule/test_utils.py", line 251, in test_update
self.assertTrue(time.time() - last_updated < .1)
AssertionError
----------------------------------------------------------------------
Ran 1912 tests in 71.563s
FAILED (failures=1)
These tests should use freezegun[1] to ensure time.time() returns the expected result.
https://pypi.python.org/pypi/freezegun
update: there are some other places that could use freezegun as well. You can find them by running:
git grep "assert.*time.*<"
There may be other time-based assertions in the tests, but at minimum the regex above should not find anything. We may want to also ensure there are no "sleep" calls in the tests but IMO that is more of a stretch goal for this issue.
Related issues