On 10/20/05, Michael Twomey <[EMAIL PROTECTED]> wrote: > I've just started dipping my toes into the turbogears water, and I'm > currently looking at the testing aspect.
People always seem to be a step ahead of me. There is a testing document due on, uh, the 11th of October :( I'm working on some deployment stuff right now, and the testing doc is next on my list. For the first version of the doc, I was going to punt on the database part. But, since you bring it up, let's talk about it. The fastest and easiest way to test with SQLObject without a doubt is using sqlite, because you can create in memory databases. I'd like to see a bit of infrastructure for setting up that database and tearing it down. That infrastructure could be used for other databases as well, but sqlite is a good choice because of the memory speed. sqlobject itself has some test utility routines for setting up databases, I believe. > While the http request testing is covered in the getting started > guide, it isn't immediately obvious to me what the preferred way to > test the sqlobject components of a turbogears site. I suspect I've > missed some docs somewhere. What's missing in this particular case is a feature to make it easier. Sounds like a good thing for the trac: http://trac.turbogears.org > So far I've come up with this (which seems to work for me): [script removed] > Does this look correct? That seemed reasonable for a single test. There's definitely more infrastructure needed, though, for running tests on larger apps and against other databases. > BTW, I also ran into a problem with util.call vs util.createRequest. > It seems that if you do a util.call before you do a util.createRequest > you get a nasty attribute error (I'm guessing that createRequest sets > things up in cherrypy): It's a bug. Can you drop a ticket in trac? http://trac.turbogears.org Thanks for bringing up a topic that is near and dear to my heart. Kevin
