[Grok-dev] grok mini-sprint progress
faassen at startifact.com
Thu Jan 21 07:01:14 EST 2010
Yesterday and today we're having a mini-sprint at the offices of the
Health Agency in Rotterdam. It's just me, Jan-Wijbrand Kolman, Sylvain
Viollon and Jan-Jaap Driessen. I'm writing this so that people who
aren't at the sprint have some idea of what is going on and where we
think Grok should be going.
What we are doing is to try to devise a way to make Grok work on top of
as few zope.app.* packages as possible.
The zope.app.* packages that we'll need to keep for now (or extract
This sets up the database, puts a root object in there, sets up
This hooks up the actual publishing so that requests can be created and
This is a WSGI frontend to the publisher. It is needed to make our
paster integration in grokcore.startup works.
We have a few packages that are particularly difficult to get rid of:
Tests in the above packages and grokcore.* packages depend on this. This
package itself depends on lots of stuff.
This package also depends on a lot of stuff, and loads tons of ZCML.
We believe that if we can cut the links on these two packages, we'll end
up with a pretty minimal configuration.
Here's a rough plan for how to do that:
This provides two major features:
* functional test setup
* browser test setup so zope.testbrowser can be used
We want to make the functional test setup work differently and based on
clean zope.testrunner layers. In a zope.* package, we'd have a test
layer that could be imported from it, that if used in a test, sets up a
functional test for this package.
So, if you'd wanted to test against a fully set up database, you'd
import the test layer from zope.app.appsetup, and if you'd want to test
against just a set up component architecture, you'd use zope.component's
test layer. The test layers should build on each other.
Finally if you want to do a browser set, you'd use the test layer from
zope.app.wsgi. We've been doing work to let zope.testbrowser talk to
WSGI instead of to zope.app.testing, and zope.app.wsgi can provide this.
We need to cut the dependency on zope.app.zcmlfiles in all packages. We
experimentally tried this in grokcore.view. It turns out that if we
include enough package's ZCML by hand, it works. It's a long list of
We ran into a philosophical issue. We use browser tests to test
grokcore.view's functionality. This however tests too much.
grokcore.view's task is to *register* views correctly with the component
architecture. The tests should only test whether those registrations are
correct. This can be done by browser tests, but that also tests whether
the whole publication process works. But grokcore.view doesn't really
need to depend on the publication process.
We believe that grokcore.view's tests should only test the
registrations. Browser tests are therefore shouldn't be part of
grokcore.view. But we also recognize that such tests are probably more
readable and writable than registration tests. It would be nice to have
a clean API (NOT zope.app.testing.ztapi, which is terrible) to check
such registrations. And the API to actually look up the registrations
should ideally be used by the query as well. The idea is that any
component registration pattern should have a higher level registration
and lookup API. And if we take the browser tests out, we might want to
move them elsewhere, but where? Grok itself?
More information about the Grok-dev