* Wichert Akkerman <wichert@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@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