[TIP] Testing the Fixture?

iain duncan iainduncan at telus.net
Thu Nov 22 00:47:56 PST 2007

On Wed, 2007-21-11 at 22:00 -0800, Titus Brown wrote:
> -> > I, however, would argue that this is a bad idea: tests should fail or
> -> > they should succeed.  Having code that relies on local code trickiness
> -> > to ignore or halt successive tests seems like a fantastic way to lose
> -> > test code.
> -> 
> -> Ok, I'll take your advice on that then. However, I'm getting a hang from
> -> nose when I make it fail in the module setup. I get the output that it
> -> failed on 0 tests, but then nose won't exit. Any idea what the below
> -> should be instead?
> CherryPy is Evil.  Its threading is causing your problems.

Yes, it appears connected to the fact that the cherrypy server doesn't
stop. Is that because a failed assertion in module level start up means
module level tear down doesn't happen?

> Meet my leetle friend, wsgi_intercept:
> 	http://ivory.idyll.org/articles/twill-and-wsgi_intercept.html
> Incidentally, the maintainer of wsgi_intercept is a fella named Kumar
> McMillan, who is also on this list.

Hmm, I was trying that out, and followed your tutorial on it, but I
couldn't get twill command driven page-to-page visits with session
variables working. I could try again I suppose, but I at least finally
got my test working with CP for now. ( I have a shopping system in
development that stores one session var as the key to the cart.) Do you
know if it's possible to use the wsgi intercept technique with the
intercept built in setup, lasting through the tests, and using session

Maybe I should just try to get rid of that session var, dunno. It's a
bit annoying 'cause it's the only Non-REST link in the system. I could
use some stupidly long random key in the url I suppose ... :/
( oops, OT! )

Thanks again!

More information about the testing-in-python mailing list