Integration testing: Start a blocking server during `unittest.setUp` before testing it?

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"开发者_如何学C 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?

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!-)

You could create a context manager to launch your test while a server is running on background.

if __name__ == '__main__':
    with background_server():
        print('Server loaded, launching the tests...')
        unittest.main(exit=False)

The code I use for background_server:

@contextlib.contextmanager
def background_server():
    # Launching the server
    pid_server = os.fork()
    if not pid_server:  # Child code
        launch_server()  # Blocking call (until signal.SIGINT)
        print('Interuption detected, server closed...')
        sys.exit()  # Closing the process

    # HACK: Wait for the server to be launched
    while True:
        try:
            requests.get("http://localhost:5000/", timeout=0.5)
            break
        except requests.exceptions.ConnectionError:
            pass
        time.sleep(0.3)

    try:
        yield
    finally:
        # Closing the server
        os.kill(pid_server, signal.SIGINT)

If serve() blocks, then your best bet is to spawn a thread in setUp to call serve(). Then you have to figure out how to stop Thrift in the tearDown method.