On Wed, Jun 24, 2009 at 3:11 PM, Chris Withers<ch...@simplistix.co.uk> wrote: > > Hi All, > > I'm wondering what the common idiom is for unit testing w.r.t. data and > transactions... > > So, coming from my ZODB background, in unit tests we usually: > > - set up the objects required > - run the code to be tested (which might change, add or delete objects) > - abort the current transaction so no changes are saved and everything > goes back to how it was prior to the start of the test > > What's the equivalent in sqlalchemy-land? > > How do I get test data needed for a specific test to exist for only that > test? > > How do I abort changes made by a test in a unittest.TestCase sublcasses > tearDown method? > > What do I do if the app framework I'm using goes and does a commit as > part of the unit test? (I wish it wouldn't... ;-) ) > > (this is in the context of a Pylons app if that makes things easier/harder)
You generally want to use a test database rather than depending on a rollback to preserve the live data, because who knows when something might go wrong (e.g.,, a stray commit you didn't notice). You can define an alternate database in test.ini. You can create and populate the database in the setUp function Nose runs, and drop the tables in the tearDown function. These functions can be run for every test or only on on entering/exiting the module, depending on how you name them them. Some people create their database in websetup.py, which I think is run during the default test configuration in Pylons. This has its advantages and disadvantages, because setup-app is a blunt instrument that can only do one thing, whereas in some situations you may only want to do part of that thing. Beware that if you have configured websetup.py this way, it will be run for every test unless you disable that. If your data is mainly added to rather than modified in place, you may want to test against real data collected a month or two ago. In that case you may want the real database or a copy of it, but the database may be too large to create/import multiple times during a test. In that case it gets a bit more difficult, plus you actually have to import the data from somewhere rather than inserting fixed dummy data. Perhaps in this case you'll want to load it from a SQL dump file made earlier, or a tab-delimited file. If you put only your read-only tests in the Pylons app and keep your read-write tests elsewhere, then it would be safer to run the read-only tests against the live database. -- Mike Orr <sluggos...@gmail.com> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
