[Twisted-Python] Testing Twisted code without trial
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Tue Jan 22 15:03:29 EST 2013
On 09:29 am, adi at roiban.ro wrote:
>On 22 January 2013 02:21, <exarkun at twistedmatrix.com> wrote:
>>On 20 Jan, 02:35 pm, adi at roiban.ro wrote:
>>>I start my pet project using Python Nose as test runner. At the
>>>Twisted not used at all.
>>>Later I discovered Twisted and start using it... but testing Twisted
>>>I resist migrating to Trial and ended up with a custom code for
>>>running Twisted tests together with Nose:
>>>I though I can share this code on the list, in case there is someone
>>>else wrestling with deferres testing outside of Trial.
>>>Any feedback or comments is much appreciated.
>>The implementation is somewhat saddening in its use of Twisted
>>(which makes it fragile and subject to easy breakage by new Twisted
>>releases) and limited platform support (it won't work on Windows,
>>You may also find problems with direct use of `reactor.iterate`, since
>>use of this API is highly discouraged due to re-entrancy issues and
>>implementation is not all that well tested by Twisted's own test
>>If it works for you, great, but I would hesitate to recommend it to
>>projects as a testing tool. As Itamar suggests, nose should be able
>>run xUnit-style tests.
>Thanks for your feedback.
>The new methods successResultOf and failureResultOf looks good, but I
>think they only work with deferred that already have a result.
>I am aware that the whole thing is fragile... and I am aware of the
>consequences of using internal non-public methods.
>I checked the code from twisted.trial.unittest.TestCase but I could
>not spot how it waits for deferreds execution.
>What part of twisted.trial.unittest.TestCase executes and waits for
>Can I use that code to implement something similar to successResultOf
>and failureResultOf but which also executes the deferred?
trial does what it does by touching a lot of internal stuff as well.
This is still bad, but at least it's our fault if it ever breaks instead
of yours. There's also a long term plan (or "plan" may be putting it
too strongly, perhaps I should say "hope") that this part of trial will
change to only use public interfaces. This will probably require
reactors actually implementing restartability, or it will require
changing the trial feature slightly (eg, so it starts a reactor, runs
all tests, then stops the reactor - if it did this, I'm sure you can
imagine how "waiting" for a Deferred would just be adding a callback to
the right place, as in any other Twisted-based application).
Are you interested in helping out with making reactors restartable? :)
>This code also works on Windows and on other Unix systems (OSX,
Okay. I expected otherwise when I saw `_UnixWaker` in the
implementation, but reading more carefully I now see that the code
doesn't ever try to instantiate or use one of these, it just needs it
for type checking. My mistake!
More information about the Twisted-Python