<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 October 2016 at 23:40, Ian Cordasco <span dir="ltr"><<a target="_blank" href="mailto:sigmavirus24@gmail.com">sigmavirus24@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail-HOEnZb"><div class="gmail-h5">-----Original Message-----<br>
From: Clay Gerrard <<a href="mailto:clay.gerrard@gmail.com">clay.gerrard@gmail.com</a>><br>
Reply: OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Date: October 11, 2016 at 00:25:10<br>
To: OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject:  [openstack-dev] requests-mock<br>
<br>
> Greetings!<br>
><br>
> Anyone have any experience to share positive or negative using<br>
> requests-mock? I see it's been used to replace another dependency that had<br>
> some problems in many of the OpenStack python client libraries:<br>
><br>
> Added to global requirements -> <a target="_blank" rel="noreferrer" href="https://review.openstack.org/#/c/104067">https://review.openstack.org/#<wbr>/c/104067</a><br>
> Added to novaclient -> <a target="_blank" rel="noreferrer" href="https://review.openstack.org/#/c/112179/">https://review.openstack.org/#<wbr>/c/112179/</a><br>
> Added to cinderclient -> <a target="_blank" rel="noreferrer" href="https://review.openstack.org/#/c/106665/">https://review.openstack.org/#<wbr>/c/106665/</a><br>
> Added to keystoneclient -> <a target="_blank" rel="noreferrer" href="https://review.openstack.org/#/c/106659/">https://review.openstack.org/#<wbr>/c/106659/</a><br>
><br>
> But I'm not sure how folks other than Jamie are getting on with it? When<br>
> writing new tests do you tend to instinctively grab for requests-mock - or<br>
> do you mostly not notice it's there? Any unexpected behaviors ever have<br>
> you checking it out with bzr and reading over the source? Do you recall<br>
> ever having any bumps or bruises in the gate or in your development<br>
> workflow because of a new release from requests-mock? No presumed fault on<br>
> Jamie! It seems like he's doing a Herculean one-man job there; but it can<br>
> be difficult go it alone:<br>
><br>
> <a target="_blank" rel="noreferrer" href="https://bugs.launchpad.net/requests-mock/+bug/1616690">https://bugs.launchpad.net/<wbr>requests-mock/+bug/1616690</a><br>
><br>
> It looks like the gate on this project is configured to run nova & keystone<br>
> client tests; so that may be sufficient to catch any sort of issue that<br>
> might come up in something that depends on it? Presumably once he lands a<br>
> change - he does the update to global-requirements and then all of<br>
> OpenStack get's it from there?<br>
><br>
> I ask of course because I really don't understand how this works [1] :D<br>
><br>
> But anyway - Jamie was kind enough to offer to refactor some tests for us -<br>
> but in the process seems to require to bring in these new dependencies - so<br>
> I'm trying to evaluate if I can recommend requiring this code in order to<br>
> develop on swiftclient [2].<br>
><br>
> Any feedback is greatly appreciated!<br>
><br>
> -Clay<br>
><br>
> 1. As you may know (thanks to some recently publicity) swift & swiftclient<br>
> joined OpenStack in the time of dinosaurs with a general policy of trying<br>
> to keep dependencies to a *minimum* - but then one day the policy changed<br>
> to... *always* add dependencies whenever possible? j/k I'm not acctually<br>
> sure what the OpenStack policy is on dependency hygiene :D Anyway, I can't<br>
> say *exactly* where that "general policy" came from originally? Presumably<br>
> crieht or gholt just had some first hand experience that the dependencies<br>
> you choose to add have a HUGE impact on your project over it's lifetime -<br>
> or read something from Joel on Software -<br>
> <a target="_blank" rel="noreferrer" href="http://www.joelonsoftware.com/articles/fog0000000007.html">http://www.joelonsoftware.com/<wbr>articles/fog0000000007.html</a> - or traveled<br>
> into the future and read the "go proverbs" and google'd "npm breaks<br>
> internet, again". Of course they've since moved on from OpenStack but the<br>
> general idea is still something that new contributors to swift &<br>
> swiftclient get acclimated to and the circle of confusion continues<br>
> <a target="_blank" rel="noreferrer" href="https://github.com/openstack/swift/blob/master/CONTRIBUTING.rst#swift-design-principles">https://github.com/openstack/<wbr>swift/blob/master/<wbr>CONTRIBUTING.rst#swift-design-<wbr>principles</a><br>
> - but hey! maybe I can educate myself about the OpenStack policy/process;<br>
> add this dependency and maybe the next one too; then someday break the<br>
> cycle!?!?<br>
><br>
> 2. <a target="_blank" rel="noreferrer" href="https://review.openstack.org/#/c/360298">https://review.openstack.org/#<wbr>/c/360298</a><br>
<br>
</div></div>Hi Clay!<br>
<br>
I have a complex set of opinions about requests-mock. First, let me<br>
start by saying that when people start asking about httpretty versus<br>
responses versus the N other libraries that do similar things versus<br>
requests-mock, I always tell them to use requests-mock. The rest are<br>
hacky and poorly done and (unlike Jamie) do not take critical feedback<br>
regarding their approach to the problem well. requests-mock has only<br>
ever improved since I've become aware of it and the only bugs it has<br>
run into have been due to changes in Requests. So, as a core developer<br>
of Requests, I would endorse requests-mock for this category of<br>
dependency.<br>
<br>
Now, my problem with requests-mock stem from the way it encourages you<br>
to write unit tests. (Or at least, the way most people in OpenStack<br>
write "unit" tests with it.) Most of the time, what you'll see is that<br>
someone starts using requests-mock and hand writes their data and<br>
response headers into the mock object. They then do something with a<br>
much higher-level object and assert things like a Resource object has<br>
the correct attributes. So they're not testing that the library makes<br>
the request the way they expect it to. They're asserting that the<br>
request is made that way AND everything else does it's job on top of<br>
that. That's not a unit test, that's an integration test.<br></blockquote><div><br></div><div>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]<br><br><br>[1] <a href="https://review.openstack.org/#/c/372656/">https://review.openstack.org/#/c/372656/</a><br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
You also might start to think that this isn't a problem, but as the<br>
shade developers found, it can be incredibly difficult to keep these<br>
up-to-date and correct. They use Betamax for that (via keystoneauth's<br>
fixture) and they use requests-mock. I think, using both appropriately<br>
will give you the test coverage you want.<br>
<br>
Either way, in this instance, I would absolutely recommend you start<br>
using requests-mock on Swift.<br>
<br>
Cheers,<br>
--<br>
Ian Cordasco<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a target="_blank" rel="noreferrer" href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a target="_blank" rel="noreferrer" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>