[Zope-dev] zope.testbrowser and WebTest (round 2)

[Brian Sutherland]

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 <brian at 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 <brian at 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 [1] to which I copied the
> AuthorizationMiddleware from zope.testbrowser trunk (moved there in
> [2]). 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
HandleErrorsMiddleware.

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
directly now.
 
> * 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.
> 
> +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
> svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3"
> sources:zope.app.wsgi="svn
> svn+ssh://svn.zope.org/repos/main/zope.app.wsgi/branches/janjaapdriessen-webtest"
> buildout:auto-checkout="zope.testbrowser zope.app.wsgi grok
> grokcore.rest" versions:WebTest=1.2.3 && bin/test-grok
> 
> -- 
> Jan-Jaap Driessen
> 
> 1) http://zope3.pov.lt/trac/changeset/120756/zope.app.wsgi/branches/janjaapdriessen-webtest/src/zope/app/wsgi/testlayer.py
> 2) http://zope3.pov.lt/trac/changeset/119878/zope.app.wsgi/trunk/src/zope/app/wsgi/testlayer.py

-- 
Brian Sutherland