Open Stack

On Tue, Oct 11, 2016 at 5:40 AM, Ian Cordasco <sigmavirus24 at gmail.com>
wrote:

> So, as a core developer
> of Requests, I would endorse requests-mock for this category of
> dependency.
>

Excellent; exactly the kind of feedback I was hoping to solicit.  If you're
looking to add this catagory of dependency - requests-mock is best-of-breed.

Although, honestly, I was also hoping to get some input from the
perspective of maintaining a client library specifically to address the
question of if this category of dependency is something that makes sense?

e.g.

Ian, you've worked on glance - so I went looking how glanceclient uses
requests_mock and found another change from Jamie:

https://review.openstack.org/#/c/141992/

In this change, it *seems* like instead of glanceclient maintaining some
stubs that are used to set explicit expectations about the external
behavior of the other system - glaceclient has *outsourced* it's
expectations to implicitly couple with whatever keystoneclient provides.
On one hand this seems like it might reduce some maintenance burden.  OTOH,
the burden of maintaining some of the expectations about the behavior of
the external system you depend on seems *related* to maintaining the glance
client?  I'm not sure if this is a great tradeoff?  Maybe?  I'm not sure if
this gets into what you were talking about wrt integration tests?  The
change I'm currently evaluating doesn't import an external fixture I don't
think... I'm not really sure what a fixture is this context?

http://requests-mock.readthedocs.io/en/latest/api/requests_mock.html?highlight=fixture#requests-mock-fixture-module

-Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161011/1c348b32/attachment.html>