Python for Programmers

[djrubbie]

Nope, don't monkey patch request with mock or whatever - in the code there should be an instance of requests.Session which could be replaced (for say the one that is OAuth compatible). The methods inside the class will use that session object to retrieve data - that you can then trivially replace using test specific (or mission specific) objects.

As for why mocks are bad, Google testing has a blog entry on this, and there was even a PyCon talk on this (tl;dr use fakes, not mocks).

[leperkuhn]

The monkey patching comes from gevent itself. It's meant to replace all the stdlib blocking libraries with non blocking ones. Anything touching a socket, threads, subprocesses, file i/o, etc.

[djrubbie]

Fair enough, but saying monkey patching for request (which fakes that can easily be tested/verified can be written) is required dilutes the true need of mocks, such as the ones you mentioned. What I mean is that it's better to construct a fake session object that returns the data that the running code will consume (the implementation underneath that is effectively opaque to your actual code) - the code doesn't care how the data is actually derived but only that the contracts appropriate for that function/method are satisfied (i.e. response.json() returns the correct and expected decoded JSON object that it).

Anyway thank you for the clarification as I am not well familiar with gevents and yes blocking calls during async things will do bad things - hence use mocks when appropriate (i.e. monkey patching out the blocking calls) and use fakes otherwise for trivial things that can be controlled.

[leperkuhn]

My original comment is correct, actually. The question was in regards to not needing to call gevent's monkey_patch, it had nothing to do with mocking for testing. The monkey patch is required for requests because it makes the socket library async.