[Dev] Mock Reactor for tests?

[Phillip J. Eby]

At 02:33 PM 6/6/2005 -0700, Brian Kirsch wrote:
>Phillip and Heikki you bring up some good points. In regards to the 
>timeout issue any client and any server code used in testing should 
>leverage the Twisted TimeoutMixin. This will force a timeout after a 
>certain number of seconds specified. Phillip, you are correct that
>there is no concept of a simulated duration. But it is easy to lower the 
>actual duration value. For example, in test_pop3client to
>lower the timeout value from 60 to 5 to force a shorter duration all I 
>have to do is popClientInstance.timeout = 5.

I understand that.  However, a single unit test that takes 5 whole 
*seconds* to run is useless (as a unit test for development purposes).  You 
should be able to run an entire subsystem worth of unit tests in 5 
seconds.  PEAK's roughly 900 unit tests run in 7 seconds on my PC, and that 
includes a variety of "simulated time" scheduling tests that if run for 
real, would take minutes.  5 seconds is totally off the scale for a unit test.

So, while I'll agree that you certainly can do what you're saying, I'm just 
pointing out that it's not going to improve on the availability of 
TDD-quality unit tests in Chandler unless you can take the timeouts down to 
zero, which still doesn't work for timing tests.


>  I guess my point was we may not need to add the extra burden of 
> maintaining our own mock reator. I think it is still worth looking in to 
> just leveraging the code twisted provides.

Sure.  But I doubt it'd be much burden - keep in mind that I've written 
these things before, with several variations, and fairly tight levels of 
integration with Twisted 1.0, as well as implementing from-scratch reactors 
for specialized purposes.  I seem to recall my first simulated-time reactor 
was only a dozen or so lines of added code.

Anyway, if you feel that StringTransport is sufficient to do loopback I/O, 
then the only other features that we would need are simulated time and the 
ability to reset between tests.  Which means it would be well worth 
proposing an ITestReactor interface to Twisted, with methods like those 
proposed by Itamar in the thread I mentioned earlier.  (Given that he 
proposed them, I imagine a patch would be welcome.)

I'll probably take a closer look at this tomorrow, to see what it would 
take to integrate my old simulated-time approach into a patch for Twisted 2.