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:
>> 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.
To get the groktoolkit tests and my company's applications to run with
Brian's zope.testbrowser+webtest branch I did the following things:
* 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, 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.
* 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 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.
In order to run the tests on the groktoolkit trunk, run:
buildout:auto-checkout="zope.testbrowser zope.app.wsgi grok
grokcore.rest" versions:WebTest=1.2.3 && bin/test-grok
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -