[Twisted-Python] Running Twisted tests with testtools
Free Ekanayaka
free at 64studio.com
Fri Feb 10 03:29:15 EST 2012
Hi Jonathan,
|--==> On Wed, 8 Feb 2012 22:15:18 +0000, Jonathan Lange <jml at mumak.net> said:
[...]
>>Even those returning deferreds and using AsynchronousDeferredRunTest? I
>>presume so, just asking to be sure.
>>
JL> Yes.
JL> (Also, you don't get sure from asking, you get sure from trying).
True, I've taken some time to read the code and try a few experiments,
and it was an highly beneficial exercise.
I now understand that the logic that deals with tests returning
deferreds is all contained in twisted.trial.unittest.TestCase and
trial-the-test-runner doesn't basically have any knowledge in this
regards. So running a testtools.testscase.TestCase decorated with
AsynchronousDeferredRunTest is pretty much transparent.
This is a nice separation of concerns, I guess it was kind of obvious
but I had never really looked into this.
>>Also, testtools has an AsynchronousDeferredRunTestForBrokenTwisted class
>>too which I believe mimics more closely what trial currently does, so
>>I'm not sure what the difference between AsynchronousDeferredRunTest and
>>AsynchronousDeferredRunTestForBrokenTwisted would be when using trial to
>>run such tests.
>>
JL> From the documentation:
JL> * Trial spins the reactor a couple of times before cleaning it up,
JL> ``AsynchronousDeferredRunTest`` does not. If you rely on this behavior, use
JL> ``AsynchronousDeferredRunTestForBrokenTwisted``.
I see, so if understand it correctly, the part that implements this
behavior in trial is the twisted.trial.util._Janitor._cleanPending
method that:
# flush short-range timers
reactor.iterate(0)
reactor.iterate(0)
which I guess is always called no matter what, while in testtools this
is an optional behavior that you get by setting _OBLIGATORY_REACTOR_ITERATIONS
like AsynchronousDeferredRunTestForBrokenTwisted does.
Beside code organization/design is this the main substantial difference
between twisted.trial.unittest.TestCase and testtools.testcase.TestCase
plus AsynchronousDeferredRunTest?
Or put it in a stronger form, if there was a compatibility class inheriting
from testtools.testcase.TestCase/AsynchronousDeferredRunTestForBrokenTwisted
and providing the same API as twisted.trial.unittest.TestCase (like
assertFailure, getSkip, etc.) would it work as a seamless drop-in
replacement, at least in principle?
Cheers,
Free
More information about the Twisted-Python
mailing list