On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
* Brian Sutherland <brian@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@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