----- Original Message ----- > From: "Paul Michali (pcm)" <p...@cisco.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Cc: jamielen...@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 …..…. p...@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) < p...@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 …..…. p...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
