AcceleratedHTTPCache and virtual hosting (collector 1447)
Hi folks, need some advice here. http://www.zope.org/Collectors/Zope/1447 ("AcceleratedHTTPCacheManager doesn't PURGE correctly for virtual hosts") has been assigned to me like forever, and I've determined to not let another year go by with this one unfixed ;-) I'd like to apply the patch and commit, once I'm sure it works correctly, but - drumroll - AcceleratedHTTPCacheManager has no test suite at all. Which means, as frequently happens with Zope 2, I have to go through the pain of setting up a test suite for the current behavior before I go changing anything. The fun thing about this is that AcceleratedHTTPCache uses httplib to send purge notifications. I don't fancy launching a dummy server of some sort. So, I'm asking for advice: How in general does one go about setting up a unit test for network client code? One thought that occurs to me is to replace httplib.HTTPConnection with a mock object of some sort that allows easy verification of its input. So we assume that httplib works, as a proper unit test should I think. How to do this? One idea is to monkeypatch httplib during the course of the test case, and replace and then when the test finishes, restore the old httplib.HTTPConnection. But this idea smells pretty bad to me. Another thought: Maybe before doing anything else, I should make the client class used by AcceleratedHTTPCache configurable, so I can more easily get a mock in there. Something like: class AcceleratedHTTPCache (Cache): client_class = httplib.HTTPConnection ... def ZCache_invalidate(self, ob): ... h = self.client_class(host) ... Then I can just do something like this during afterSetUp(): cache = AcceleratedHTTPCache() cache.client_class = MockHTTPConnection Any better ideas? testing-network-stuff-hurts-my-head-ly-yrs, -- Paul Winkler http://www.slinkp.com
On 3 Dec 2005, at 15:57, Paul Winkler wrote:
One thought that occurs to me is to replace httplib.HTTPConnection with a mock object of some sort that allows easy verification of its input. So we assume that httplib works, as a proper unit test should I think. How to do this? One idea is to monkeypatch httplib during the course of the test case, and replace and then when the test finishes, restore the old httplib.HTTPConnection. But this idea smells pretty bad to me. Another thought: Maybe before doing anything else, I should make the client class used by AcceleratedHTTPCache configurable, so I can more easily get a mock in there. Something like:
I like the secondary route, but I'm not sure the production code should contain "testing only" turds. :) I have done the first route on many occasions, mostly with the LDAPUserFolder where I actually replace a class in the python-ldap module with one that fakes out a LDAP connection object so I can operate on it: # Do some namespace manipulation to make use of FakeLDAP from Products.LDAPUserFolder.tests import FakeLDAP sys.modules['ldap'] = FakeLDAP This could also be done in setUp/tearDown, which I should really do because this code does not clean up after itself. If you happened to run other code after running the test and with the same running interpreter that just happens to use the python-ldap module you'd be in bad shape ;) jens
On Dec 3, 2005, at 11:08 AM, Jens Vagelpohl wrote:
On 3 Dec 2005, at 15:57, Paul Winkler wrote:
One thought that occurs to me is to replace httplib.HTTPConnection with a mock object of some sort that allows easy verification of its input. So we assume that httplib works, as a proper unit test should I think. How to do this? One idea is to monkeypatch httplib during the course of the test case, and replace and then when the test finishes, restore the old httplib.HTTPConnection. But this idea smells pretty bad to me. Another thought: Maybe before doing anything else, I should make the client class used by AcceleratedHTTPCache configurable, so I can more easily get a mock in there. Something like:
I like the secondary route, but I'm not sure the production code should contain "testing only" turds. :)
FWIW, I put "testing only" turds all the time in production code. It's pretty sane as long as you put a comment in the code that says "this dance performed to service unit tests" or somesuch. And it makes life much easier than needing to dummy up *everything*. - C
Jens Vagelpohl wrote at 2005-12-3 16:08 +0000:
...
Another thought: Maybe before doing anything else, I should make the client class used by AcceleratedHTTPCache configurable, so I can more easily get a mock in there. Something like:
I like the secondary route, but I'm not sure the production code should contain "testing only" turds. :)
We could use monkey patching for this -- used only for testing purposes. The "five" people included a small piece of my software ("ReuseUtils.rebind.rebindFunction") in "five" (therefore, it should now be somewhere in Zope 2.8 and above) which makes monkey patching such as replacing "httplib" by some mockup rather painless (i.e. without copying code to be tested). -- Dieter
Dieter Maurer wrote:
We could use monkey patching for this -- used only for testing purposes.
Yup, I've had extensive success with this too, for example, to get consistent dates during date-based tests. I'm also -1 on havign functionality in production code that's there purely to support unit tests... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Winkler wrote:
Hi folks, need some advice here.
http://www.zope.org/Collectors/Zope/1447 ("AcceleratedHTTPCacheManager doesn't PURGE correctly for virtual hosts") has been assigned to me like forever, and I've determined to not let another year go by with this one unfixed ;-)
I'd like to apply the patch and commit, once I'm sure it works correctly, but - drumroll - AcceleratedHTTPCacheManager has no test suite at all. Which means, as frequently happens with Zope 2, I have to go through the pain of setting up a test suite for the current behavior before I go changing anything.
The fun thing about this is that AcceleratedHTTPCache uses httplib to send purge notifications. I don't fancy launching a dummy server of some sort. So, I'm asking for advice: How in general does one go about setting up a unit test for network client code?
One thought that occurs to me is to replace httplib.HTTPConnection with a mock object of some sort that allows easy verification of its input. So we assume that httplib works, as a proper unit test should I think. How to do this? One idea is to monkeypatch httplib during the course of the test case, and replace and then when the test finishes, restore the old httplib.HTTPConnection. But this idea smells pretty bad to me.
Another thought: Maybe before doing anything else, I should make the client class used by AcceleratedHTTPCache configurable, so I can more easily get a mock in there. Something like:
class AcceleratedHTTPCache (Cache): client_class = httplib.HTTPConnection ... def ZCache_invalidate(self, ob): ... h = self.client_class(host) ...
Then I can just do something like this during afterSetUp():
cache = AcceleratedHTTPCache() cache.client_class = MockHTTPConnection
Any better ideas?
You could modify the testing code do an adapter lookup for a component used to do the HTTP client stuff, and then arrange to register your dummy object in a test. I imagine that this would be useful for more than just testing; for instance, if I want to purge a whole tier of Squids, right now the only way to do that is to write a proxy-proxy (one version I wrote once was called PageAssassin) which distributes the PURGE request to them. An adapter-based scheme would allow me to replace the stock version with one which distributed the PURGE directly. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkcf8+gerLs4ltQ4RAp1yAKCuIZDPKujDQR3qDxUn7Ik0y0u2tQCfXiWC iDSM7oV4ABVktTwCMzXfN8c= =MpSy -----END PGP SIGNATURE-----
On Sat, Dec 03, 2005 at 11:29:48AM -0500, Tres Seaver wrote:
Paul Winkler wrote: (snip)
... AcceleratedHTTPCacheManager has no test suite at all.
Erm. Actually it does; Tres added it on the TRUNK many months ago. I was looking at a 2.7 checkout! Mea culpa. However, the test suite currently *does* fire up an HTTP server (on a hardwired port, 1888). As I said, I'm not crazy about this, it seems needlessly fragile and makes the test code harder to read than I'd like. So I'm inclined to follow Tres' adapter suggestion, it seems like The Right Thing to me. I'll modify the existing suite accordingly on a branch. To the other respondents: Thanks for the suggestions, but I do not consider making AcceleratedHTTPCacheManager more flexible to be a "test turd". Tres outlined a real use case for changing the code (see below). I don't understand why you guys consider this more invasive than monkeypatching, which is capable of causing obscure breakage in far-flung tests. But thanks anyway.
You could modify the testing code do an adapter lookup for a component used to do the HTTP client stuff, and then arrange to register your dummy object in a test. I imagine that this would be useful for more than just testing; for instance, if I want to purge a whole tier of Squids, right now the only way to do that is to write a proxy-proxy (one version I wrote once was called PageAssassin) which distributes the PURGE request to them. An adapter-based scheme would allow me to replace the stock version with one which distributed the PURGE directly.
Tres.
-- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
To the other respondents: Thanks for the suggestions, but I do not consider making AcceleratedHTTPCacheManager more flexible to be a "test turd". Tres outlined a real use case for changing the code (see below). I don't understand why you guys consider this more invasive than monkeypatching, which is capable of causing obscure breakage in far-flung tests. But thanks anyway.
Coding for testability is quite important, and is a credo of some of the trendy methodologies these days. I consider it perfectly acceptable to have a class attribute ConnectionClass for httplib.HTTPConnection or a method like "getConnection" that can then be subclassed or modified during tests. Provided it does not important performance issues. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
participants (7)
-
Chris McDonough -
Chris Withers -
Dieter Maurer -
Florent Guillaume -
Jens Vagelpohl -
Paul Winkler -
Tres Seaver