Hi Jason, A few comments that may clear things up and make it easier:
- you can set model.__connection__ to something else, if you need to change it for testing purposes - PackageHub does not even look up the connection configuration until it's needed. It should be possible to close and clear the connection as well when doing tests. - sqlite is *great* for unit tests because you can create in-memory databases. You could use sqlite most of the time and sometimes run against your real database engine to verify correct operation. I don't remember what all is done by SQLObject's test code, but I was guessing that we'd be able to use that code. There's no reason that tests really need to use the PackageHub for their connections. Foreign key constraints are always a pain when dropping a database. I don't know if anyone's written code for SQLObject to make this more convenient. Kevin On 11/4/05, Jason Chu <[EMAIL PROTECTED]> wrote: > So far my application isn't at a stage to do functional or even unit tests > of the controllers, but I do have a bunch of model objects and a little bit > of logic around them. > > I read the little testing doc and it says that there is no support for > testing model objects. I'm now trying to figure out what would be needed. > > The way I've done SQLObject testing before was starting with a fresh > database each test and only creating the data that I needed for that > specific test. It's slow, I know, but it's precise. > > The problem, in the case of TurboGears, is the PackageHub. All my objects > are created with PackageHub or AutoConnectionHub connections and I'd have > to change the connection for the different SQLObject classes any time I > wanted to use them. Will I essentially be reimplementing > sqlobject.tests.setupClass and sqlobject.tests.InstalledTestDatabase to be > able to test my SQLObject classes through testgears? > > Would I want to get around the PackageHub entirely or just run > turbogears.database.set_db_uri before importing any model objects? I'd > still have to worry about creating the tables before the tests, but I'm > pretty sure I can get all that from the InstalledTestDatabase class. > > One more quick question: is there an easy way to clear all tables without > running amuck of foreign key constraints? > > Jason > > -- > If you understand, things are just as they are. If you do not understand, > things are just as they are. > > > -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
