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

Travis B. Hartwell slt5v at cc.usu.edu
Wed Oct 1 22:24:35 EDT 2003


Hey all,

In my recent efforts to update the Beyond code base to use recent,
preferred, and non-deprecated Twisted developments such as new cred, I
have encountered a few problems in updating the unit tests to match my
changes.  The unit tests as they stood before my changes used the old
pyunit module.  After successfully converting the tests on the old
code base to use twisted.trial (and fixing a probable bug in the
process that pyunit didn't expose), I attempted to get them to work
with my changes.  That's where the problems started happening.  From
my experience and looking through the unit tests written for Twisted,
I have come up with the following questions.  As a background, the
client and server that I am testing in Beyond is implemented using PB.

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.
    
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.
    
3.  From that, if I use the twisted.protocols.loopback module, how do
    I set up callbacks for events such as logging in?  As I am using
    it now, it appears that things just hang and nothing is ever
    completed.  For example, in one of my tests, I have this code,
    with self.p being my portal and self.c being an instance of my PB
    client:

        accum = []
        factory = pb.PBClientFactory()
        deferred = factory.login(UsernamePassword("guest", "guest"), client=self.c)
        deferred.addCallbacks(accum.append, self.errorReceived)
        loopback.loopbackTCP(self.p, self.c)

    It just sits there, not advancing beyond the loopbackTCP call.
    
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()?
    
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.

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.

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


I hope these questions make sense.  I felt the mailing list was a
better forum for this than IRC because I had detailed questions.
Also, would it be appropriate for general cases of answers to these
questions (especially ones like #5 and #7) to be added to the "Unit
Tests in Twisted" howto?  I would be willing to put those appropriate
into there after someone answers my questions. :)

Thanks a million,
and slowly learning,

Travis




More information about the Twisted-Python mailing list