Is it possible/reasonable to test form submission using testutil? I was thinking that I could just emulate the form submission by passing the appropriate args on the url as query parameters with testutil.create_request . . but that approach doesn't replicate the problem I'm seeing with my code when I hit the page with a form submit from a browser.
Should I be using twill or paste.fixture instead? If so, which is superior? From some light blog reading, it looks to me like twill has the edge, but I'd be interested in the opinion of someone with more experience in these two tools.
thanks,-Ken
I definitely think we should support both Twill and paste.fixture in
TurboGears 2, but we need to pick a default, and I think that
paste.fixture offers the path of least resistance for TG2. And I've
been working with it quite a bit recently, and it seems to be very
pythonic, reasonable, and I'm sure that we will be able to make
testing a lot nicer in tg2 than tg1 was.
Having a good set of twill+wsgi intercept recipies will be a huge boon
to TurboGears and Pylons users, as it would be nice to be able to
write some tests that sometimes run in process and sometimes run
against the full server stack -- for instance when writing "deployment
tests" that verify that a given deployment setup actually works ;)
--Mark
why not jump right into webtest?
http://pythonpaste.org/webtest/
It adds yet another requirement but this is the next generation of
paste.fixture so it will be better maintained and already offers some
nicer features plus an even more pythonic interface. One nicety is
how it integrates with lxml.html to provide xpath and other useful
access to HTML docs (even tries hard to support broken or janky
markup). This is not required, btw, and will "not work" gracefully if
you don't have lxml.html installed. Note that this specific feature
also requires lxml2, which may still be in beta.
Kumar
> Here's a brief comparison of twill & paste.fixture based on my current
> understanding:
>
> twill:
> + good documentation (there's even a short book)
> + wide adoption. 78k vs 2k hits in a simplistic googlefight [2]. I've
> encountered examples of using twill with CherryPy, Turbogears, Django, Zope,
> Pylons, etc. during my wanderings.
> + twill-sh can be used as a test recorder. There's also a maxq extension,
> but I'm not sure what it's current state is.
>
> paste.fixture:
> + access to wsgi environment makes testing controller results possible.
> + nice pythonic API.
> + pylons uses it, and tg2 will be based on pylons.
>
>
> Other notes:
>
> * I've hacked up twill to support access to the wsgi environment using
> wsgi_intercept [3], but Titus naturally wants me to clean it up before
> accepting it. I plan on working on it more this weekend.
I definitely think we should support both Twill and paste.fixture in
TurboGears 2, but we need to pick a default, and I think that
paste.fixture offers the path of least resistance for TG2. And I've
been working with it quite a bit recently, and it seems to be very
pythonic, reasonable, and I'm sure that we will be able to make
testing a lot nicer in tg2 than tg1 was.
Having a good set of twill+wsgi intercept recipies will be a huge boon
to TurboGears and Pylons users, as it would be nice to be able to
write some tests that sometimes run in process and sometimes run
against the full server stack -- for instance when writing "deployment
tests" that verify that a given deployment setup actually works ;)
--Mark
This sounds like a great idea. If we had a stable test interface
between TG1 and 2 (and some hopeful CherryPy3 version of TG) that
would be amazingly helpful for people as they migrate forward. And I
was never super-excited about the way we monkeyed arround with
cherrypy internals to get the TG1 test interface, and it's slowed us
up more than once when we tried to do the CherryPy 3/1.1 work, and
again when thinking about the TG2 upgrade path.
--Mark Ramm