* Wichert Akkerman <[email protected]> [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 <[email protected]> [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 _______________________________________________ Zope-Dev maillist - [email protected] 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 )
