In my latest Python project, utilizing Twisted, I've tried to be good at using the unittest module. At a high level, I'm building two RESTful APIs designed specifically to talk to each other. For most requests, I can just use DummyRequest and test the rendered values against an expected constant and that's been working fine.
However, I've got a few cases where the design requires a request on one server that (among other things) then sends a request to the other server, but doesn't really care about the response. What matters is that the request happens. 
Like I said, I can test that functionality on the other side perfectly fine, but I'm getting stumped on how to test to ensure that the data was sent over. My ideas so far are either

Set up a dummy test server that just checks to see if the request was made and validates the input - Seems flaky and too much effort
Set up a decorator to wrap certain tests and modify urllib.urlopen to report when it was called, what we tried to retrieve, and allow me to simply return a known result there.

I'm leaning towards the second option as it seems more pythonic, but also a bit hacky.
Thoughts?
I don't know much about Twisted or how you set up your system under test, but could you start two servers on a single thread? One of them would be the one you are testing and another would be just a dummy that can accept any request. In addition to that, the dummy would store info that it has received the call. After initiating the operation on the first server that causes it to call the second one, you could then assert that the second one has received a request.
Unit-testing client-server interaction in Twisted