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

[Wolfgang Schnerring]

* Wichert Akkerman <wichert at wiggy.net> [2011-01-31 09:46]:
> On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
>> So I'm curious: What are the differences bewteen WebTest and
>> wsgi_intercept? Is one preferable to the other?
>
> If I remember correctly WebTest wraps the WSGI app object directly and 
> does not require monkeypatching urllib. To send requests to the app 
> under testing you call WebTest post/get methods, which directly call the 
> WSGI app.

Thanks for clarifying, that does indeed make sense. I guess I should
have researched wsgi_intercept and WebTest in more detail. :/

* 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.)

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.

> 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).

>> 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

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.

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.

Wolfgang