A couple quick comments re testing & twill.
I'm starting to use 'nose' for unit testing, and it's great.
In conjunction with my 'nose' unit tests, I've also just added a fairly simple interface for specifying (a) an app to run and (b) a twill script to use to test that app. Watch planetpython for my blog post on that.
The maxq recorder for twill sucks. Or should that be Sucks? I'm hoping to get some work done on it soon, but right now it's not terribly useful. (Ironic, given that one of the reasons I wrote twill was so that I could play back recorded tests.)
I'm intrigued by John's opinion of zope.testbrowser. I liked the look of it too, but it'd be a big change for twill and I'm not feeling that energetic right now ;).
Why not define a new URI scheme, e.g. 'wsgi://', and then put in a urllib2-like WsgiHandler or some such? That could potentially be a simpler way to do "in process" tests than monkeypatching urllib... either way, I like the idea of getting twill/mechanize/* to talk to things without going through HTTP.
John -- I promise I'll start using the new mechanize code soon ;). Right now I'm a bit overwhelmed, but it's on my TODO list.
Why not define a new URI scheme, e.g. 'wsgi://', and then put in a urllib2-like WsgiHandler or some such?
Lots of code expects a constrained set of URI schemes. http and https, in particular; I know I don't generally write code with extensible schemes in mind. And either way, I think a WSGI app would have to be mounted into place... though I perhaps automatic mounting would be possible, where you did wsgi://path.to.module/object or something like that. And I suppose Paste Deploy has URIs, though the specific schemes it uses are a bit ambiguous in this case.
I don't think the monkeypatching would be hard. I guess it's just a question of whether it is wise. But it seems as good as anything to me.# Ian Bicking
At the risk of repeating myself, no monkeypatching is required to add wsgi: URL support -- urllib2 is designed so that adding new URL schemes and behaviour is easy iff you have access to the OpenerDirector instance (the thing you call .open(urlOrRequest) on). Titus, as the author of twill, clearly does have such access, though I don't know if it's also exposed as part of the twill API.
Point taken -- rather than breakage with wsgi:// (which I thought might be clean) I will look at subverting urllib2. The goal will be to produce a WSGI-compliant server interface into which any WSGI app can be plugged & played.
This is a good direction for twill, IMO, so I'm moderately enthusiastic about implementing it, too.
A few additional comments:
zope.testbrowser looks nice, but it's unclear to me what the compelling advantage is. I've got to look at it more before I make my life more complicated by trying to switch to it... ;)
the twill API doesn't provide direct access to anything mechanize-tic, but the full mechanize interface is of course accessible to extension functions, which are just Python (of course!).
Finally, even if twill becomes WSGI-aware, writing the tests is going to be a huge pain. (Hmm, maybe if I get the BickingBot entangled in twill he'll write a WSGI recorder!)
Simple (but working) implementation of in-process testing with twill: <a href="http://www.advogato.org/person/titus/diary.html?start=119">discussed here</a>.
I don't imagine there'd be much purpose in re-writing twill for zope.testbrowser, would there? Would just introduce an unneccesary extra layer of complexity.# anonymous
oops, that last comment about twill / zope.testbrowser was me.
Why invent the 'wsgi:' scheme, when you can just reimplement urllib2.HTTPHandler?# anonymous