After a nice blurb or two about my lightning talk at PyCon '06, I thought I'd practice my screencast fu by recording (a version of) my lightning talk. Without further ado, here's a screencast of a rerun of my lightning talk. (Yeah, I know it kinda sucks; I'm still working on the process!)
This took a fair amount of investigatory work. I started out by using SnapZ Pro X, for Mac OS X, which produced hideously large files of generally low quality. After lots of wasted effort, I gave up and switched to pyvnc2swf. I knew (from Chad Whitacre's efforts) that it could work, I just didn't know how well it worked.
Well, the short and sweet of it is that pyvnc2swf is a fantastic piece of software, and with only a minor amount of geek fiddling, I recorded the screencast above. (I actually gave up on using pyvnc2swf directly on my Mac; the screencast was recorded over the network, which is a pretty nifty feature of pyvnc2swf...)
Audio was more of a problem. I ended up recording with Quicktime Pro at the same time as I was doing the screencast, then saved as AIF and re-encoded with LAME before overlaying it onto the SWF file. There were a few mishaps in this process, because QuickTime doesn't save as MP3 (!?!?) and the AIFF file it generated doesn't contain good header info. Amusing nonetheless.
wsgi_intercept & mock_http
While I was at PyCon, an old acquaintance from Reed, Marc Hedlund, contacted me about wsgi_intercept. Apparently he needed to build a mock HTTP server to test client HTTP code, and upon discovering wsgi_intercept thought two things: (a) this is perfect! and (b) hey, I know this guy! Weird, eh? Pity he wasn't at PyCon...
Anyhoo, he very kindly donated a simple mock HTTP example to the project, and I just checked that in. So now you can mock not only the TCP connection but also the entire server side. Heh.
twill and django
In addition to Michael Twomey's overnight hack using wsgi_intercept stuff to test Django, some other people appear to be using twill with django.
Googling about, I found this interesting discussion of unit tests and twill. That led to this file (it's a download link) which was probably not meant to be entirely public, but too late, google finds all...
I looked over the source to understand how they were using twill. A few comments and thoughts, some for them, some for me:
- twill's browser.get_html() doesn't actually return the tidy-ed or
BeautifulSoup-ed HTML. It probably should, or it should
at least have an option for it.
- twill.set_output(fp) will now endeavor to redirect all output to
the given fp, so they don't have to do the (painful!) stdio remapping
any more.
- I ended up writing my own test_follow_links for our MailOnnaStick app. Good idea. Should probably be in the
std twill extensions lib at this point...
- I was also thinking of adding in hooks to require that page visits
be successful, etc. Looks like they could make use of those; good to know.
- It would be cool to have random generators for forms that would
let you fill in things like name, address, and zip fields with syntactically
correect (or intentionally incorrect... hmmm...) input.
- Use coverage.py to look at the code coverage of your twill tests. That way, you can pretty easily figure out what parts of your Web app are completely missed by your Web tests.
Anyway, no good idea how to find these people, but I'd be interested in hearing their success/failure stories with twill.
--titus