On 09:29 am, a...@roiban.ro wrote: >On 22 January 2013 02:21, <exar...@twistedmatrix.com> wrote: >>On 20 Jan, 02:35 pm, a...@roiban.ro wrote: >>>Hi, >>> >>>I start my pet project using Python Nose as test runner. At the >>>start, >>>Twisted not used at all. >>>Later I discovered Twisted and start using it... but testing Twisted >>>requires trial. >>> >>>I resist migrating to Trial and ended up with a custom code for >>>running Twisted tests together with Nose: >>> >>>https://github.com/chevah/chevah-rhinoplasty >>> >>> >>>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 >>internals >>(which makes it fragile and subject to easy breakage by new Twisted >>releases) and limited platform support (it won't work on Windows, >>afaik). >> >>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 >>its >>implementation is not all that well tested by Twisted's own test >>suite. >> >>If it works for you, great, but I would hesitate to recommend it to >>new >>projects as a testing tool. As Itamar suggests, nose should be able >>to >>run xUnit-style tests. >> >>Jean-Paul > >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 >the deferred? > >Can I use that code to implement something similar to successResultOf >and failureResultOf but which also executes the deferred?
Hi Adi, 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, >Solaris) 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! Jean-Paul _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
