If you come up with some techniques you'd like to share, please post them to the wiki:
http://trac.turbogears.org This *is* an area that needs to be filled in... I just haven't personally had the time to do so, so any help is a boon.. Thanks! Kevin On 11/4/05, Jason Chu <[EMAIL PROTECTED]> wrote: > 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. > > > -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
