Ian Bicking: the old part of his blog

Re: Zope 3 functional doctests

Cool, that's just the kind of thing I was thinking of. It seemms a tad crude -- what with the raw requests right in the code. It seems like with a little care (plus something based on mechanize's stateful browser object) you could improve the narrative quality nicely. For instance (from your example):

>>> print http("""
... POST /frogpond/resources/lily/edit.html HTTP/1.1
... Authorization: Basic mgr:mgrpw
... Content-Length: 29
... Content-Type: application/x-www-form-urlencoded
...
... field.title=Foo&CANCEL=Cancel
... """)
HTTP/1.1 303 See Other
...
Location: http://localhost/frogpond/resources/lily
...

Might instead be:

>>> b.click('CANCEL')
>>> b.response.status
303 See Other
>>> b.response.headers.location
'http://localhost/frogpond/resources/lily'

Note that b (the browser object) specifically has knowledge of the context and the last request, so in this case you are submitting a form that you just received. I think this statefulness better represents the thing you are testing, plus doctests are sequential and narrative anyway -- might as well take advantage of it. In general I've thought that the Zope 3 doctests I've seen seemed like they didn't have enough scaffolding; there should be more helper functions written solely for the purpose of doctesting.

Anyway, it's still cool that it's useful and works for you. The XML doctest extension I wrote might also be useful for this sort of thing -- though it still needs wildcards.

Comment on Zope 3 functional doctests
by Ian Bicking