[openstack-dev] [infra]Requesting consideration of httmock package for test-requirements in Juno

Jamie Lennox jamielennox at redhat.com
Tue Apr 8 19:04:13 UTC 2014



----- Original Message -----
> From: "Paul Michali (pcm)" <pcm at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Cc: jamielennox at gmail.com
> Sent: Wednesday, April 9, 2014 12:09:58 AM
> Subject: [openstack-dev] [infra]Requesting consideration of httmock package for test-requirements in Juno
> 
> Reposting this, after discussing with Sean Dague…
> 
> For background, I have developed a REST client lib to talk to a H/W device
> with REST server for VPNaaS in Neutron. To support unit testing of this, I
> created a UT module and a mock REST server module and used the httmock
> package. I found it easy to use, and was able to easily create a sub-class
> of my UT to run the same test cases with real H/W, instead of the mock REST
> server. See the original email below, for links of the UT and REST mock to
> see how I used it.
> 
> 
> I created a bug under requirements, to propose adding httmock to the
> test-requirements. Sean mentioned that there is an existing mock package,
> called httpretty , which I found is used in keystone client UTs), and should
> petition to see if httmock should replace httpretty, since the two appear to
> overlap in functionality.
> 
> I found this link, with a brief comparison of the two:
> http://marekbrzoska.wordpress.com/2013/08/28/mocking-http-requests-in-python/
> 
> So… I’m wondering if the community is interested in adopting this package
> (with the goal of deprecating the httpretty package). Otherwise, I will work
> on reworking the UT code I have to try to use httpretty.
> 
> Would be interested in peoples’ thoughts, especially those who have worked
> with httpretty.
> 
> Thanks in advance!

So I introduced HTTPretty into the requirements and did the work around keystoneclient and am well aware that it has a few warts.

At the time we were going through the changeover from httplib to requests and httpretty gave a good way to change over the library and ensure that we hadn't actually changed the issued requests at all. If we had already been on requests i don't know if i'd have made the same choice.

In general I am in favour of mocking the response layer rather than the client layer - whether we do this with httpretty or httmock doesn't bother me that much. Honestly I don't think a global patch of the requests Session object is that much safer that a global patch of the socket interface, if anything requests is under development and so this interface is less defined.

What i would like to see though is this mocking transferred into fixtures like in https://review.openstack.org/#/c/77961/ and have the actual choice in mock library hidden behind those fixtures. Is this a pattern that httmock can handle? or something else again?


Jamie

 
> PCM (Paul Michali)
> 
> MAIL …..…. pcm at cisco.com
> IRC ……..… pcm_ ( irc.freenode.com )
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
> 
> 
> 
> On Apr 4, 2014, at 10:44 AM, Paul Michali (pcm) < pcm at cisco.com > wrote:
> 
> 
> 
> 
> I’d like to get this added to the test-requirements for Neutron. It is a very
> flexible HTTP mock module that works with the Requests package. It is a
> decorator that wraps the Request’s send() method and allows easy mocking of
> responses, etc (w/o using a web server).
> 
> The bug is: https://bugs.launchpad.net/neutron/+bug/1282855
> 
> Initially I had requested both httmock and newer requests, but was requested
> to separate them, so this is to target httmock as it is more important (to
> me :) to get approval,
> 
> 
> The review request is: https://review.openstack.org/#/c/75296/
> 
> An example of code that would use this:
> 
> https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/vpn/device_drivers/notest_cisco_csr_rest.py
> https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/vpn/device_drivers/cisco_csr_mock.py
> 
> Looking forward to hearing whether or not we can include this package into
> Juno.
> 
> Thanks in advance!
> 
> 
> PCM (Paul Michali)
> 
> MAIL …..…. pcm at cisco.com
> IRC ……..… pcm_ ( irc.freenode.com )
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list