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/