Open Stack

On 11 October 2016 at 23:40, Ian Cordasco <sigmavirus24 at gmail.com> wrote:

> -----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.
>

Note that I 100% agree with this. Particularly with things like
keystoneauth in the mix and the client Manager objects in the way the tests
are badly scoped. In practice though it's been a really easy conversion
process practice most clients write their tests like this. Particularly in
swiftclient where the client methods have quite a direct relationship with
the request that is produced, eg [1]


[1] https://review.openstack.org/#/c/372656/


> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161012/a2d2bf00/attachment.html>