On Sat, Mar 05, 2011 at 01:07:58AM +0100, Jan-Jaap Driessen wrote:
> Hello from the grok department,
> On 4 March 2011 11:48, Brian Sutherland <br...@vanguardistas.net> wrote:
> > On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote:
> >> Hello,
> >> 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:
> >> http://svn.zope.org/groktoolkit/trunk
> >> 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.
> To get the groktoolkit tests and my company's applications to run with
> Brian's zope.testbrowser+webtest branch I did the following things:
Great, thanks a lot!!!
> * I created a branch of zope.app.wsgi trunk  to which I copied the
> AuthorizationMiddleware from zope.testbrowser trunk (moved there in
> ). The three middleware components (Transaction, Authorization and
> HandleErrors) are needed to make the groktoolkit tests pass. The
> AuthorizationMiddleware is not available on Brian's branch
I've added the AuthorizationMiddleware to zope.testbrowser.wsgi and
added some tests for it. It doesn't look like it'll be much of a
maintenance headache being very simple with no dependencies.
> , but is
> available on zope.testbrowser trunk. If we can land this middleware in
> zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer.
> In my opinion, this middleware should be part of zope.testbrowser,
> because handleErrors is part of the IBrowser interface.
Hmm, the TransactionMiddleware looks very app-specific, as does the
In fact, I think you'll find that with my branch the
HandleErrorsMiddleware is a no-op and can be removed. The
'wsgi.handleErrors' environment variable is set in zope.testbrowser.wsgi
> * The `http caller` in zope.app.wsgi.testlayer is used in
> grokcore.rest. On my branch, I rewrote the http caller to use WebTest
> and _APP_UNDER_TEST instead of wsgi_intercept. The import from
> zope.testbrowser is bothering me; can we put the http caller in
> zope.testbrowser? The http caller returns a FakeResponse instance,
> which could very well be a WebTest TestResponse. The FakeResponse
> wrapper is merely used to fix the current tests.
I see. I think the layer just needs to become better about exposing the
global application under test. I've just committed a patch to make the
.app property a get_app classmethod. So you can do:
global_app_under_test = zope.testbrowser.wsgi.Layer.get_app()
rather than access _APP_UNDER_TEST directly.
I'd rather not move the http caller to zope.testbrowser as I'm not sure
what functionality it provides over just using webtest.TestApp directly.
> * I fixed some tests in grok and grokcore.rest to use the
> WebTest-style http caller.
> > 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.
Ok, committed this. I've also allowed domains like test.example.com.
> In order to run the tests on the groktoolkit trunk, run:
> bin/buildout sources:zope.testbrowser="svn
> buildout:auto-checkout="zope.testbrowser zope.app.wsgi grok
> grokcore.rest" versions:WebTest=1.2.3 && bin/test-grok
> Jan-Jaap Driessen
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -