Hi Jason, I discovered that after the fact when I was going through the tickets. Thanks!
Kevin On 11/14/05, Jason Chu <[EMAIL PROTECTED]> wrote: > I attached the file to the ticket: > http://trac.turbogears.org/turbogears/ticket/67 > > Jason > > On Sat, Nov 12, 2005 at 10:51:25AM -0500, Kevin Dangoor wrote: > > > > Hi Jason, > > > > This does sound good. I'd like to take a look at it, if you'd be > > willing to contribute it. > > > > Kevin > > > > On 11/7/05, Jason Chu <[EMAIL PROTECTED]> wrote: > > > 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. > > > > > > > > > > > > > > > -- > > 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
