Open Stack

-----Original Message-----
From: Clay Gerrard <clay.gerrard at gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: October 11, 2016 at 00:25:10
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject:  [openstack-dev] requests-mock

> Greetings!
>
> Anyone have any experience to share positive or negative using
> requests-mock? I see it's been used to replace another dependency that had
> some problems in many of the OpenStack python client libraries:
>
> Added to global requirements -> https://review.openstack.org/#/c/104067
> Added to novaclient -> https://review.openstack.org/#/c/112179/
> Added to cinderclient -> https://review.openstack.org/#/c/106665/
> Added to keystoneclient -> https://review.openstack.org/#/c/106659/
>
> But I'm not sure how folks other than Jamie are getting on with it? When
> writing new tests do you tend to instinctively grab for requests-mock - or
> do you mostly not notice it's there? Any unexpected behaviors ever have
> you checking it out with bzr and reading over the source? Do you recall
> ever having any bumps or bruises in the gate or in your development
> workflow because of a new release from requests-mock? No presumed fault on
> Jamie! It seems like he's doing a Herculean one-man job there; but it can
> be difficult go it alone:
>
> https://bugs.launchpad.net/requests-mock/+bug/1616690
>
> It looks like the gate on this project is configured to run nova & keystone
> client tests; so that may be sufficient to catch any sort of issue that
> might come up in something that depends on it? Presumably once he lands a
> change - he does the update to global-requirements and then all of
> OpenStack get's it from there?
>
> I ask of course because I really don't understand how this works [1] :D
>
> But anyway - Jamie was kind enough to offer to refactor some tests for us -
> but in the process seems to require to bring in these new dependencies - so
> I'm trying to evaluate if I can recommend requiring this code in order to
> develop on swiftclient [2].
>
> Any feedback is greatly appreciated!
>
> -Clay
>
> 1. As you may know (thanks to some recently publicity) swift & swiftclient
> joined OpenStack in the time of dinosaurs with a general policy of trying
> to keep dependencies to a *minimum* - but then one day the policy changed
> to... *always* add dependencies whenever possible? j/k I'm not acctually
> sure what the OpenStack policy is on dependency hygiene :D Anyway, I can't
> say *exactly* where that "general policy" came from originally? Presumably
> crieht or gholt just had some first hand experience that the dependencies
> you choose to add have a HUGE impact on your project over it's lifetime -
> or read something from Joel on Software -
> http://www.joelonsoftware.com/articles/fog0000000007.html - or traveled
> into the future and read the "go proverbs" and google'd "npm breaks
> internet, again". Of course they've since moved on from OpenStack but the
> general idea is still something that new contributors to swift &
> swiftclient get acclimated to and the circle of confusion continues
> https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles
> - but hey! maybe I can educate myself about the OpenStack policy/process;
> add this dependency and maybe the next one too; then someday break the
> cycle!?!?
>
> 2. https://review.openstack.org/#/c/360298

Hi Clay!

I have a complex set of opinions about requests-mock. First, let me
start by saying that when people start asking about httpretty versus
responses versus the N other libraries that do similar things versus
requests-mock, I always tell them to use requests-mock. The rest are
hacky and poorly done and (unlike Jamie) do not take critical feedback
regarding their approach to the problem well. requests-mock has only
ever improved since I've become aware of it and the only bugs it has
run into have been due to changes in Requests. So, as a core developer
of Requests, I would endorse requests-mock for this category of
dependency.

Now, my problem with requests-mock stem from the way it encourages you
to write unit tests. (Or at least, the way most people in OpenStack
write "unit" tests with it.) Most of the time, what you'll see is that
someone starts using requests-mock and hand writes their data and
response headers into the mock object. They then do something with a
much higher-level object and assert things like a Resource object has
the correct attributes. So they're not testing that the library makes
the request the way they expect it to. They're asserting that the
request is made that way AND everything else does it's job on top of
that. That's not a unit test, that's an integration test.

You also might start to think that this isn't a problem, but as the
shade developers found, it can be incredibly difficult to keep these
up-to-date and correct. They use Betamax for that (via keystoneauth's
fixture) and they use requests-mock. I think, using both appropriately
will give you the test coverage you want.

Either way, in this instance, I would absolutely recommend you start
using requests-mock on Swift.

Cheers,
--
Ian Cordasco