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

[Brian Sutherland]

On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
> * Brian Sutherland <brian at vanguardistas.net> [2011-01-31 09:54]:
> > On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
> >> I'd very much like there to be *one* way of doing WSGI with the
> >> testbrowser, and at first blush I don't care whether that's WebTest or
> >> wsgi_intercept or whathaveyou, as long as it fulfills its purpose. 
> >
> > We have already committed to wsgi_intercept integration for the long
> > term. It was released in zope.testbrowser 3.11 a few days ago, right? If
> > we are to have only one way to do this, then wsgi_intercept must be it.
> 
> I definitely don't see this as set in stone, *at all*. Yes, we've had a
> release that uses wsgi_intercept for talking to WSGI apps. (And yes, we
> didn't ask anyone for their opinion on it, and I'm sorry about that.
> However, I guess the development process in the Zope community is an
> entirely different issue, sigh.)

Yeah, a totally different issue that I don't really wanna get involved
in right now.

> But I feel the important point about this regarding compatibility is not
> the underlying technology, but the API, i. e. that
> - zope.testbrowser.wsgi.Browser is a Testbrowser
> - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to
> facilitate the test setup.
> 
> I think as long as we preserve this API (which seems sound to me, but of
> course I'm biased ;-), we're free to change stuff under the hood.

Ok, I think that that API is preservable. However I would like to make
the layer optional by adding an wsgi_app keyword argument to Browser. So
you can do:

    >>> browser = Browser(wsgi_app=app)

where app is a WSGI application.

Some people in the non-zope world are not too fond of layers, or use
incompatible testrunners. We shouldn't force layers on them.

> > But I'm ambivalent about only having one way to do things. I think
> > having both integrations in zope.testbrowser is not such a bad thing.
> > Having the test suite run over 2 different integrations is definitely
> > good.
> 
> Maybe I'm missing something, but when I think about the task at hand
> from the client's perspective, then the only sentence that matters to me
> is, "give me a zope.testbrowser that talks to this WSGI callable".
> 
> Which means a) I couldn't care less how that's done internally as long
> as it doesn't cause me any hassle and, more importantly b) I do *not*
> want to have to think about it and/or make a choice about the underlying
> mechanism. I want the library to have done that research (as we are
> doing right now). And to me this task seems straightforward enough to
> not warrant pluggability -- on the contrary, I feel it's so narrow in
> scope it outright *forbids* it (but again, I may be missing something).

Well, it appears that now we've reached some sort of consensus as to
what base library to use. So yeah, having *one* way to do things is just
fine.

> >> I'll gladly review your branch, but I'd like to know the motivation
> >> behind it.
> >
> > Only ~30% of the branch is the implementation of the WebTest connection.
> >
> > The other ~70% of the branch is a refactoring of the test suite. That's
> > where the reduction in test dependencies comes from. The test fixture on
> > the branch is a reasonably minimal WSGI application run via the WebTest
> > connection.
> 
> I'd prefer if we treated this as two separate steps, then:
> a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
> b) extract the testbrowser part that talks to the Publisher

Initially I did them together because it was the only way to get very
good test coverage of the WebTest integration. If we do it this way,
between steps a and b we'll have poor coverate. But that's not so bad as
the code has already been well tested on my current branch.
 
> As to (a), I'll still need to look at your code, but as I said I'm
> all in favour of using WebTest instead of wsgi_intercept.

I'll try make a branch for this in the next week or so for you to review.

> As to (b), I saw you moved the code to zope.app.testing. I have a
> few ideas in that area which I'll contact you off-list about.

Sure!

> Wolfgang
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )

-- 
Brian Sutherland