[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
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
accum = 
factory = pb.PBClientFactory()
deferred = factory.login(UsernamePassword("guest", "guest"), client=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.
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,
More information about the Twisted-Python