Ian Bicking: the old part of his blog

Re: Best of the web app test frameworks?

From the article:

Zope 3 emphasizes testing, but I have to admit that I am unimpressed by the functional testing

Zope 3.2 will include zope.testbrowser which is a much nicer way to do functional tests. See http://svn.zope.org/Zope3/trunk/src/zope/testbrowser/README.txt?rev=40035&view=markup for example usage.

It is also usable outside of Zope, and I hope on packaging up a stand-alone version around the time 3.2 is released (December). If I get time I'd also like to do a WSGI version.

Comment on Best of the web app test frameworks?
by Benji York

Comments:

zope.testbrowser looks like it has a nicer API than mechanize, at least for testing (speaking as the author of mechanize), and I see Stephan Richter is hoping to implement the same API using Selenium -- cool.

BTW, mechanize should support

easy_setup mechanize==dev

properly as soon as the latest setuptools is released... would be nice to fetch zope.testbrowser the same way

# John Lee

Yes, that's much better indeed. Now I can't remember quite why I wrapped my application in an object, instead of using a browser object as the central metaphor. In the end it's not that much different, except that some things like "back" don't exist for an application, and it's not as stateful (which has pluses and minuses).

It looks like zope.browser actually uses HTTP requests? WSGI would definitely be nice, as it would allow in-process requests, something that I have found very convenient. Seeing the framework's nice-formatted HTTP exception reports is not particularly useful when you are running automated tests. I also like that I can send out-of-band information; for instance, I use REMOTE_USER to set the username (or sometimes put it in test-specific configuration), instead of simulating a full login. Then I don't need fake logins, or to put my password in the tests, etc.

Another feature that I added to paste.fixture -- in part after looking at Rails' and CherryPy's tests -- is the framework hooks which allow frameworks to record internal information into the response object. This means you can simultaneously test the full-stack rendering and response, and internal details like what variables were passed to the template. Obviously you can only do this in-process.

# Ian Bicking

It looks like zope.[test]browser actually uses HTTP requests?

For Zope 3 it directly communicates with the in-process publisher. Not only is it much faster that way, you can have non-testbrowser code do other types of tests (as you mention below). There's also a generic browser object you can use that makes connections over the wire for testing "remote" applications or doing non-testing tasks.

I intend on integrating the same way with WSGI; zope.testbrowser would actually be a WSGI server into which you would plug the application(s) under test.

Of course this fits into my desire to make Zope 3 paste.deploy compatible.

# Benji York