On Wed, Feb 08, 2006 at 11:12:00AM +0530, suresh wrote:
-> [EMAIL PROTECTED] 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
_______________________________________________
twill mailing list
[email protected]
http://lists.idyll.org/listinfo/twill
