[Twisted-Python] Simulating time for reactor

David Bolen db3l at fitlinxx.com
Mon Jan 12 12:35:35 EST 2004

I was wondering if the subject of being able to override the concept
of "time" for the Twisted reactor has come up before?

In the context of testing code that depends on reactor delayed events
(e.g., such as callLater), up to this point we've been controlling the
test by having the test override the timers used in the callLater
call, and then controlling the point at which the reactor "cranks"
(via iterate) so that we can control when the timer would or wouldn't
fire with respect to other events under test.

While this works well, it does mean that we aren't testing with actual
time values in the objects under test, thus our tests aren't enforcing
a particular time value in the design.  But I don't want the tests to
have to wait for the real time values (which can be lengthy) during
their normal execution.

For our own objects that manage events based on time delays, we have
those objects centralize their access to time through a single method,
which we can override in a mock version of that object for testing -
and thus the test has explicit control on the notion of "time" when it
executes.  It seems to me that something similar might be useful as a
standard part of the reactor.

For example, if IReactorCore included a now() or time() method which
was the only way it grabbed system time, then tests could mock up a
reactor to be installed at the start of a test and just override that
one method to control time.  From looking at base.py in the Twisted
distribution for example, it only appears that a few uses of
time.time() would have to be tweaked.

Anyway, I was curious if this has come up before, and if so, how else
have people tested reactor based code that has lengthy timers involved?

-- David

More information about the Twisted-Python mailing list