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