views:

343

answers:

1

I have a stock Pylons app created using paster create -t pylons with one controller and matched functional test, added using paster controller, and a SQLAlchemy table and mapped ORM class. The SQLAlchemy stuff is defined in the init_model() function rather than in module scope (and needs to be there).

Running python setup.py test raises an exception because nose is somehow causing init_model() to be called twice within the same process, so it's trying to create a model that already exists.

I can hackishly fix this by setting and checking a global variable inside init_model(), but (a) I'd rather not, and (b) third-party libraries such as AuthKit that dynamically define models break the tests as well, and can't be so easily changed.

Is there a way to fix nose tests for Pylons, or should I write my own test script and just use unittest, loadapp, and webtest directly? Any working examples of this?

+2  A: 

I would try debugging your nosetest run. Why not put:

import pdb;pdb.set_trace()

in the init_model() function and see how it is getting invoked more than once.

With PDB running you can see the stack trace using the where command:

w(here)
Print a stack trace, with the most recent frame at the bottom.
An arrow indicates the "current frame", which determines the
context of most commands.  'bt' is an alias for this command.
Casey
Using pdb showed that the stock tests/__init__.py provided by paster was first running the setup-app command, then actually running the tests, and this accounts for init_model being called twice. I commented out the setup-app line, and everything works fine. I guess the remaining question is why paster puts that in there when it doesn't seem necessary and doesn't work out-of-the-box.
Jason S
jasonjs: my understanding/guess is that \_\_init\_\_.py is trying to create the database tables for you so you wouldn't need to run paster setup-app test.ini manually before you can run the tests.
Marius Gedminas