Question

I’m writing a service using Thrift and need to apply some tests to ensure that it operates/responds as expected. To accomplish this, the most robust approach seems to be to use the unittest module.

I’d like to start the service in “test” mode (starts on a specific “test” port, uses “test” data, etc) from directly within the unit test’s setUp method, but calling serve() blocks at that point waiting for connections.

What would be the best approach for starting the service so that the tests can execute and the service can be brought-down cleanly using the tearDown method?

Answer 1

The “complete isolation” that unittest provides is excellent for unit tests (what it’s designed for) but not necessarily for integration tests — I see the attraction of reusing unittest for those, I do it myself to take advantage of special test runners &c that we have around, but, realizing that it’s something of a force fit to use unittest for integration tests, I try to compensate by coding rather differently than I’d code unit tests.

When I have to spawn a server in integration testing, I tend to do the spawning at the start of the module, in a separate process — via subprocess, or by other means appropriate to your installation, if you want to run it in a separate node or whatever — and register with atexit the termination code that will send that server the termination request when my test-module is all finished. That’s not as “cleanly separated” as unit testing would require, but I find it’s good enough for integration testing, and amortizes the overhead of starting and initializing the server, which may be very high indeed, across multiple tests.

Even if you’re keen to use setUp and tearDown, I still recommend using a separate process (and a separate node, if you have plenty of those lying around in a “continuous build farm” or the like). Using a different thread in the same process, as @Ned’s answer suggests, strikes me as risky — might easily produce unwanted interactions between the server and the tests, hiding some bug or causing others.

If I understand correctly you’re trying to run the server not just on the same process, but even in the same thread as the tests, and that seems definitely a bad idea to me — of course it will block everything, unless the server is coded very particularly indeed!-)