[twill] Article on testing CherryPy and Quixote Web apps with twill.

[titus@caltech.edu]

On Wed, Feb 08, 2006 at 11:12:00AM +0530, suresh wrote:
-> titus at caltech.edu wrote:
-> > Hi all,
-> > 
-> > I just posted this.  Let me know what you think.
-> > 
-> > 	http://www.advogato.org/article/874.html
-> > 
-> > --titus
-> 
-> Hi Titus:
-> 
-> Nice article! Thanks for wsgi_intercept.
-> 
-> Did you see John Lee's comment on Ian Bicking's blog at
-> 
-> http://blog.ianbicking.org/best-of-the-web-app-test-frameworks.html
-> 
-> Specifically:
-> 
-> > In-process would mean that it calls an application in the same process, instead of generating an HTTP request. So an exception in the application would go all the way up to the command runner (py.test, unittest, etc).
-> > # Ian Bicking
-> > 
-> >     Oh, I see, seems you're right.
-> >     You'd need a urllib2.HTTPHandler that does what you want instead of real HTTP, then subclass mechanize.Browser to override the handler_classes attribute, and persuade twill to use your Browser subclass.
-> >     # John Lee
-> > 
-> >         It would be a clever hack to monkeypatch urllib2.HTTPHandler to override requests to certain hosts and instead send them to in-process WSGI applications. That would mean that any urllib2-using Python app should be able to work this way, including Twill or whatever else.
-> >         # Ian Bicking
-> > 
-> >             That's what I meant, but no "monkeypatch" is required: you just use a different handler instead of urllib2.HTTPHandler.
-> >             # John Lee
-> 
-> Is this a possible way to implement this? If so, it would help 
-> mechanize, twill and zope.testbrowser and make writing unit tests a lot 
-> easier.

Hi, Suresh -- that's exactly what wsgi_intercept does, and I've
implemented it for all of the Web testing frameworks. ;)

See

	http://darcs.idyll.org/~t/projects/wsgi_intercept/README.html

for details.

cheers,
--titus