Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Python - Twisted and Unit Tests

I'm writing unit tests for a portion of an application that runs as an HTTP server. The approach I have been trying to take is to import the module that contains the HTTP server, start it. Then, the unit tests will use urllib2 to connect, send data, and check the response.

Our HTTP server is using Twisted. One problem here is that I'm just not that familiar with Twisted :)

Now, I instantiate our HTTP server and start it in the setUp() method and then I stop it in the tearDown() method.

Problem is, Twisted doesn't appear to like this, and it will only run one unit test. After the first one, the reactor won't start anymore.

I've searched and searched and searched, and I just can't seem to find an answer that makes sense.

Am I taking the wrong approach entirely, or just missing something obvious?

like image 808
Dave Avatar asked Oct 16 '09 01:10

Dave


3 Answers

Here's some info: Writing tests for Twisted code using Trial

You should also look at the -help of the trial command. There'a lot of good stuff in trial! But it's not always easy to do testing in a async application. Good luck!

like image 154
Etienne Avatar answered Nov 13 '22 23:11

Etienne


I believe that for unit testing within Twisted you're supposed to use TwistedTrial (it's a core component, i.e., comes with the Twisted tarball in the twisted/trial directory). However, as the URL I've pointed to says, the doc is mostly by having a look through the source (including sources of various Twisted projects, as they're tested with Trial too).

like image 7
Alex Martelli Avatar answered Nov 13 '22 22:11

Alex Martelli


As others mentioned, you should be using Trial for unit tests in Twisted.

You also should be unit testing from the bottom up - that's what the "unit" in unit testing implies. Test your data and logic before you test your interface. For a HTTP interface, you should be calling processGET, processPOST, etc with a mock request, but you should only be doing this after you've tested what these methods are calling. Each test should assume that the units tested elsewhere are working as designed.

If you're speaking HTTP, or you need a running server or other state, you're probably making higher level tests such as functional or integration tests. This isn't a bad thing, but you might want to rephrase your question.

like image 4
Karl Anderson Avatar answered Nov 13 '22 23:11

Karl Anderson