[Dev] Mock Reactor for tests?

[Phillip J. Eby]

Hi.  I've heard recently that there are some tests that ideally would need 
to run under the Twisted reactor, in order to properly exercise the 
functionality under test.  However, there are a number of issues including 
the possible need for multiple uses of run/stop, dependency on external 
servers, test duration, etc.

There is, however, a relatively straightforward solution: use a mock 
reactor.  I've successfully used this approach in the past to test 
event-driven libraries, although it was only with a subset of the full 
Twisted reactor capabilities.  A mock reactor can be stopped, reset, and 
started as many times as you like, because it doesn't rely on hooking a GUI 
event loop, running in a separate thread, or anything like that.

A mock reactor can run in "simulated time", which means that it uses a 
time() function that runs faster than "real" time.  For example, if you 
schedule a callback, and there's no pending simulated I/O or other 
scheduled calls, the simulated time jumps ahead to the next scheduled callback.

One additional side benefit of simulated time is that it's deterministic 
and therefore can be reliably reproduced in repeated tests.  In PEAK, for 
example, I once wrote tests for some components that might be compared to 
WakeupCallers in Chandler.  I had several scheduled to wake up on various 
intervals, and the test then verified that they had run at all the times 
they should have.  Since the time is simulated, there were no rounding 
errors or clock precision to take into account, and the tests could 
instantaneously whether they were simulating seconds, minutes, or even 
hours of scheduling operations.

A mock reactor for Chandler tests could also use my "mockets" (fake 
sockets) library in order to avoid doing any "real" network I/O, allowing 
servers to listen and clients to connect to addresses on a virtual network 
that exists only in the process' memory, thereby avoiding the complexity of 
using external processes to set up and tear down servers or depending on 
other servers being up and having connectivity to them.

Although I don't have a complete mock reactor implementation, I do have 
most of the prerequisites and experience that would be needed to implement 
one, if anybody is interested.  So, if you have things (like Zanshin, 
Chandler client protocols, etc.) that need reactor-based testing, and would 
be interested in helping me test a mock reactor for your test cases, let me 
know.  It's also possible that this could be a joint project with the 
Twisted folks; as early as last year, Itamar expressed an interest in 
allowing test reactors to run using simulated time:

http://twistedmatrix.com/pipermail/twisted-python/2004-January/006982.html

And I would be surprised if they're not interested in having a mocket-based 
reactor as well.  The last hacking I did on Twisted was around 1.1, so it 
might take me some time to get familiar with the 2.0 reactor 
interfaces.  However, unless there are major differences I don't expect it 
to be difficult to do; Twisted is designed to isolate code from the 
underlying transport mechanism in use.  About the only "interesting" part 
would likely be SSL/TLS, since I doubt M2Crypto and OpenSSL will want to 
talk to mocket objects instead of real sockets.  It might be necessary to 
create mock SSL "Transport" objects as well as a mock reactor.