Well here's something interesting. In the simple cases, PackageHub doesn't try to open a connection until it's actually trying to access the database. If you have a subclass of a subclass of a SQLObject (in my case it's SomeClass->Modifiable->SQLObject) some of the metaclass magic behind SQLObject tries to access that connection when you import the module.
I don't know enough about metaclasses to really help narrow it down more than that. I guess I'll try the in-memory sqlite databases and some custom creation, drop, and connection opening code in my tests. Thanks, Jason On Fri, Nov 04, 2005 at 02:06:31PM -0500, Kevin Dangoor wrote: > > 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 > -- If you understand, things are just as they are. If you do not understand, things are just as they are.
pgpjEkqcSqHo2.pgp
Description: PGP signature
