[Twisted-Python] Running Twisted tests with testtools

[Free Ekanayaka]

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