<div>
                    Hi Piper,
                </div><div><br></div><div>`successResultOf` is intended to be called on a Deferred which has a result (meaning `Deferred.errback` or `Deferred.callback` has been called on it already.) [1] In this case presumably your blocking call hasn’t finished (or even started?) by the time the assertion is executed, hence the Deferred has no result.</div><div><br></div><div>The usual case for using `successResultOf` is when you have a Deferred that you’re delivering results to synchronously (probably by way of calling `Deferred.callback` from your test) to determine if the callback chain produces the expected final result.</div><div><br></div><div>Without debating the merits of preferring to avoid interaction with the real world in unit tests, you can return a Deferred from your test method to run the reactor for you until the Deferred has fired and its callbacks have run. [2] You probably want to add some callbacks, to perform some assertions about the result, to the Deferred you’ll be returning.</div><div><br></div><div>[1] <http://twistedmatrix.com/documents/current/api/twisted.trial._synctest._Assertions.html#successResultOf></div><div>[2] <http://twistedmatrix.com/documents/current/core/howto/testing.html#leave-the-reactor-as-you-found-it></div>
                <div><div><br></div>-- <br>Jonathan<div><br></div></div>
                 
                <p style="color: #A0A0A8;">On Friday 30 May 2014 at 8:13 AM, Piper Masden wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div dir="ltr">I have some Klein code that uses deferToThread for I/O. It looks something like this:<div><br></div><div>@app.route('/', methods=['GET']</div><div>def index(request, *args, **kwargs):</div><div>
    d = deferToThread(some_blocking_db_select_function)</div><div><br></div><div>    def serialize(db_object):</div><div>        return json.dumps({</div><div>            'id': db_object,</div><div>            })</div>
<div>    d.addCallback(serialize)</div><div>    return d</div><div><br></div><div>I have a test that executes this function, and the deferToThread returns a Deferred, but that deferred never fires its callback, and so when I use successResultOf expecting a success result, no result is found.</div>
<div><br></div><div>When I use twistd to run the Klein application, everything works fine (the deferred fires and I get a json string in the body of the response). What's different about the trial environment that deferToThread might not fire its callback? Do I need to explicitly set up a thread pool in trial that I don't have to set up using twistd?  Any help would be appreciated.</div></div></div><div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>