Hello from the grok department, On 4 March 2011 11:48, Brian Sutherland <brian@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@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: * 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, 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.
+1 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/janjaapdrie... 2) http://zope3.pov.lt/trac/changeset/119878/zope.app.wsgi/trunk/src/zope/app/w...