On 11 October 2016 at 23:40, Ian Cordasco <[email protected]> wrote:
> -----Original Message----- > From: Clay Gerrard <[email protected]> > Reply: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > Date: October 11, 2016 at 00:25:10 > To: OpenStack Development Mailing List <[email protected]> > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
