On Fri, Jan 16, 2009 at 7:47 AM, Ivan Sagalaev <man...@softwaremaniacs.org>wrote:
> > Karen Tracey wrote: > > For the most part this change should be invisible, except for the speed > > improvement when running tests. However, if you have tests that need to > > actually test the effects of transaction commit or rollback, you will > > now need to use a django.test.TransactionTestCase instead of a > > django.test.TestCase. > > Just ran the new code with our tests and about 2/3 of them became > broken. My first hypothesis is it's caused by testing views with > self.client. We use TransactionMiddleware that explicitly commits > transaction on view's successful return. So the first test that does > "self.client.get(...)" leaves fixtures data in the database and all > subsequent attempts to load the same fixtures are failing. > Hmm, not sure what is going on here. Django's admin_views testscase uses client and fixtures, and doesn't have a problem. It should not happen that data loaded by one TestCase persists in the database to another test. TestCase setup starts a transaction and disables access to the transaction routines, so commits done by the called code don't actually get committed. TestCase cleanup rolls back the transaction started by TestCase setup. So I'm concerned how you are getting bleed over from one test to the next...that shouldn't happen. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
