Question

Let’s say I have this blob of code that’s made to be one long-running thread of execution, to poll for events and fire off other events (in my case, using XMLRPC calls). It needs to be refactored into clean objects so it can be unit tested, but in the meantime I want to capture some of its current behavior in some integration tests, treating it like a black box. For example:

# long-lived code
import xmlrpclib
s = xmlrpclib.ServerProxy('http://XXX:yyyy')
def do_stuff():
    while True:
        ...
        if s.xyz():
            s.do_thing(...)

_

# test code
import threading, time
# stub out xmlrpclib
def run_do_stuff():
    other_code.do_stuff()

def setUp():
    t = threading.Thread(target=run_do_stuff)
    t.setDaemon(True)

def tearDown():
    # somehow kill t
    t.join()

def test1():
    t.start()
    time.sleep(5)
    assert some_XMLRPC_side_effects

The last big issue is that the code under test is designed to run forever, until a Ctrl-C, and I don’t see any way to force it to raise an exception or otherwise kill the thread so I can start it up from scratch without changing the code I’m testing. I lose the ability to poll any flags from my thread as soon as I call the function under test.

I know this is really not how tests are designed to work, integration tests are of limited value, etc, etc, but I was hoping to show off the value of testing and good design to a friend by gently working up to it rather than totally redesigning his software in one go.

Answer 1

I think I found a solution that does what I was looking for: Instead of using a thread, use a separate process.

I can write a small python stub to do mocking and run the code in a controlled way. Then I can write the actual tests to run my stub in a subprocess for each test and kill it when each test is finished. The test process could interact with the stub over stdio or a socket.