On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote:
> On Fri, 4 Mar 2011 10:15:18 +0100
> Brian Sutherland <br...@vanguardistas.net> wrote:
> > > In zope.app.wsgi all those idiosyncracies are more or less
> > > handled by a WSGI middleware. I guess you can reuse it.
> > >
> > > One of the purpose of the zope.app.wsgi implementation was to be
> > > able to convert the existing tests just by changing the import, and
> > > get ride of zope.testbrowser dependencies on the crazy
> > > zope.app.testing nobody-knows-what-it-does-and-does-everything in
> > > Grok (without adding many others). Which worked perfectly.
> > I'll definitely look into reusing the middleware.
> > But, tell me, how do I run all the grok tests? (So I can see what
> > idiosyncracies are required)
> There is a Grok ToolKit, that works exactly like the Zope ToolKit:
> If you run this buildout you should get a ./bin/test-grok command
> that runs all the tests, using z3c.recipe.compattest.
> Actually, I think you can start by testing only grokcore.view. I
> guess it is one of the base packages that uses a lot the test browser.
Ok, there are 2 grokcore.view failures with my branch.
The first is due to the Basic Auth header and is fixable by adding the
middleware we were talking about.
The other is more interesting, in
src/grokcore/view/ftests/url/redirect.py. It seems that that test is
actually making calls over the network to google's servers. Probably not
a good thing.
The new behaviour (probably not good either) is to send the request to
the application even if the hostname is "www.google.com".
I would guess that the right behaviour would be to raise an error if the
hostname is not "localhost" or 127.0.0.1.
> Sylvain Viollon -- Infrae
> t +31 10 243 7051 -- http://infrae.com
> Hoevestraat 10 3033GC Rotterdam -- The Netherlands
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -