[Zope-dev] Re: AcceleratedHTTPCache and virtual hosting (collector 1447)

Tres Seaver tseaver at palladion.com
Sat Dec 3 11:29:48 EST 2005


-----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 at 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-----



More information about the Zope-Dev mailing list