[Twisted-Python] Writing unit tests with Trial for Twisted Applications

[Christopher Armstrong]

On Wed, Oct 01, 2003 at 08:24:35PM -0600, Travis B. Hartwell wrote:
> 1.  Does proper testing necessitate or at least include actually
>     communicating over a port for the client and server?  I see this
>     is done for the PB tests and several others, but not for many.

Well, this is actually usually the easiest way to test your code;
otherwise, you need to deal with crap like fake transports, etc. If
you do test over the network, make sure you listen on a local-only
interface (i.e., '127.0.0.1') and use a portno of 0. e.g.:

        self.port = reactor.listenTCP(0, self.svr, interface="127.0.0.1")
        self.portno = self.port.getHost()[-1]

> 2.  Closely related, what is the proper way to connect the client and
>     server?  When I made changes, the t.test.test_pb.IOPump that the
>     tests were using didn't seem to work.  According to spiv, this may
>     not be the preferred connecting method to use anymore.

Well, if you do what I said above, then you just need to use regular
connectTCP(self.portno, fac).

> 3.  [moot question deleted]
>
> 4.  Regardless of the method used, what is the proper way to have the
>     reactor keep going until there are no more events?  I need
>     something analogous to test_pb.IOPump.pump() or flush(), if IOPump
>     is not to be used.
> 
>     trial.unittest.TestCase.runReactor()?

Well, you don't really need "until there are no more events" --
usually, you just run the reactor until some state is reached, e.g.:

        while not l:
            reactor.iterate()

assuming that something triggered by running the reactor will
eventually make `l' True (e.g., if l started as an empty list, by
appending something to it). runReactor is only useful for
timing-related tests.

> 5.  When is the proper time to use unittest.deferredResult?  I see it
>     used in some cases, yet in other cases regular callbacks and
>     errbacks are used.

Well, any time you just want to get the result of a Deferred and don't
want to add a callback, you can use deferredResult. Some people
writing tests that use callbacks might not have known about
deferredResult, or don't like it, or needed to take advantage of
callback chaining, or whatever.

> 6.  Realted to that, when I added callbacks and errbacks, they didn't
>     seem to get executed.  Yet looking at test_newcred.py, on line 89
>     for example, they are added and then immediately the result is
>     checked.  Does this work because I am listening on a port?  Or was
>     my doing this not working originally because the client and server
>     were not connected?  Later in the same file deferredResult is used.
>     I'm not understanding what the expected behavior is then.

Well, it's probably because you're not running the reactor properly,
or something. I can't say more without seeing the code :)

> 7.  Is it preferred to use unittest.TestCase.assertEqual to the plain
>     assert?  I see both used in various places in the Twisted tests.

Well, when you use the self.assert* methods, trial marks the tests as
"Failures", rather than "Errors", which occur when any other exception
is raised from the test. Not a really big difference. Also, assert
statements don't get run when python -O is used.


-- 
 Twisted | Christopher Armstrong: International Man of Twistery
  Radix  |          Release Manager,  Twisted Project
---------+     http://twistedmatrix.com/users/radix.twistd/