[Twisted-Python] Getting rid of "DirtyReactorWarning"

Jonathan Lange jml at mumak.net
Wed May 30 02:47:01 MDT 2012

On Fri, May 18, 2012 at 9:21 PM,  <exarkun at twistedmatrix.com> wrote:
> On 15 May, 10:26 am, itamar at itamarst.org wrote:
>>I have a ticket open for allowing tests that look like this, where each
>>run has a new reactor instance:
>>def test_somethingShouldHappen(self, reactor):
>>      result = []
>>      reactor.listenTCP(...)
>>      self.runReactor(reactor)
>>      self.assertEqual(result, ["hooray"])
>>Further thought suggests however that this doesn't add much,
>>necessarily, over the current "return a Deferred" idiom for most users.
>>Experience with ReactorBuilder framework that has similar testing
>>mechanism suggests it's far too easy to fail to stop the reactor.
>>Moreover, things like coiterate() don't work since they rely on
>>pre-imported global reactor, and given the "from twisted.internet
>>reactor" idiom this testing style won't work well for many people's
>>But! ReactorBuilder tests are superior in one way: no
>>DirtyReactorWarning. You don't have to wait until all connections are
>>closed, which is difficult, or make sure to cancel every timeout. This
>>makes test writing simpler.
>>Perhaps we should get rid of DirtyReactorWarning for regular
>>Deferred-returning tests as well, then. We have all the infrastructure
>>we need, after all, for canceling scheduled events and disconnecting
>>descriptors. We might want to log when we do so, to help debug things,
>>but we already have cleanup code mostly implemented in trial anyway,
>>it seems like DirtyReactorWarning doesn't usually make future tests
>>anyway since we do run cleanup.
>>Threaded code might still be a problem, but that's the case for current
>>tests now, and even switching to a new style of tests as above would
>>only somewhat mitigate the issue.
> I think you should talk to jml about his ideas for a new base
> `TestCase`-like class which is better factored with respect to its
> handling of Twisted-related reponsibilities.

In a nutshell, TestCase.run is delegated to separate strategy object.
Relevant code is:

  TestCase: http://bazaar.launchpad.net/~testtools-committers/testtools/trunk/view/head:/testtools/testcase.py
(grep -i runtest)
  RunTest: http://bazaar.launchpad.net/~testtools-committers/testtools/trunk/view/head:/testtools/runtest.py
(that's the strategy object)
  Twisted RunTest:
  reactor control code:

The last is significantly better factored and tested than the
equivalent code in trial. This is faint praise.


More information about the Twisted-Python mailing list