[Zope-dev] Re: AcceleratedHTTPCache and virtual hosting (collector 1447)
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 RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AcceleratedHTTPCache and virtual hosting (collector 1447)
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AcceleratedHTTPCache and virtual hosting (collector 1447)
-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 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
