On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
> * Brian Sutherland <br...@vanguardistas.net> [2011-01-30 16:04]:
> > I've finally finished refactoring my WebTest/testbrowser branches,
> > basically doing this:
> > - Integrate with WebTest. zope.testbrowser.webtest.Browser is a new
> > Browser implementation that uses webtest.TestApp to drive a WSGI
> > application. This allows simple and direct testing of WSGI
> > applications.
> > - Re-write the test application as a pure WSGI application using WebOb.
> > Run the existing tests using the WebTest based Browser
> > - Move zope.app.testing based Browser into zope.app.testing (leaving
> > backwards compatibility imports in-place).
> > This is a very big change, so I would appreciate anyone who would take a
> > look at these branches before I merge:
> Michael Howitz and I recently polished the integration of
> zope.testbrowser and wsgi_intercept to accomplish pretty much the same
> things you mentioned. (I'm aware that you two exchanged some emails
> about it, but don't know any details).
> So I'm curious: What are the differences bewteen WebTest and
> wsgi_intercept? Is one preferable to the other?
The differences I've seen between the two libraries:
* WebTest doesn't require a global setup/teardown. (no zope.testing
* With WebTest it's more difficult to accidentally end up sending
real HTTP requests over the internet.
I'm probably missing quite a few though.
Another interesting datapoint is the number of downloads of each package
13000 downloads in 2 years
18500 downloads in 2 months
> 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.
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
> 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
Attached is a patch for my branch to run the test suite with the
wsgi_intercept integration. I havn't committed it yet as it has multiple
A way forward may be to fix the wsgi_intercept integration so that it
can run the full test suite then merge my branch without the WebTest
integration. However I would prefer to merge the WebTest integration as
is and fix the wsgi_intercept integration.
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope )
--- tests/test_doctests.py (revision 120009)
+++ tests/test_doctests.py (working copy)
@@ -17,26 +17,45 @@
-def make_browser(*args, **kw):
+def make_webtest_browser(*args, **kw):
app = zope.testbrowser.ftests.wsgitestapp.WSGITestApplication()
return zope.testbrowser.webtest.Browser(app, *args, **kw)
+ def make_wsgi_app(self):
+ return zope.testbrowser.ftests.wsgitestapp.WSGITestApplication()
flags = doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS
- suite = doctest.DocFileSuite(
+ webtest_suite = doctest.DocFileSuite(
+ wsgi_suite = doctest.DocFileSuite(
+ wsgi_suite.layer = WsgiInterceptLayer()
wire = doctest.DocFileSuite('over_the_wire.txt', optionflags=flags,
wire.level = 2
- return unittest.TestSuite((suite, wire))
+ return unittest.TestSuite((wsgi_suite, webtest_suite, wire))
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -