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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
