Ok, I have something that I've found works well for me. I created a class that extends unittest.TestCase called DBTest. DBTest creates the database connection, introspects your model (right now by looking at <project>.model and creating everything that extends SQLObject), and creates all the tables for you.
Across tests, it drops all the tables and recreates them. Each test looks very similar to a regular unittest.TestCase, there are just a few extra things: - The test class extends DBTest instead of unittest.TestCase - Any setUp or tearDown methods need a 'DBTest.setUp(self)' or 'DBTest.tearDown(self)' as the first line, respectively. Internally, it uses a sqlite in memory database. Is this something you'd like some code for? I don't know how easy it would be for turbogears to introspect your model (right now, DBTest looks at the module it's in and then looks at module.model). Catwalk and Identity both need you to specify where your model is... Jason On Fri, Nov 04, 2005 at 02:30:57PM -0500, Kevin Dangoor wrote: > > 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 > -- If you understand, things are just as they are. If you do not understand, things are just as they are.
pgpQBjBhbeGVC.pgp
Description: PGP signature
