I see ... thanks for the explanation. patrick
On Apr 17, 3:02 pm, Karen Tracey <kmtra...@gmail.com> wrote: > On Sat, Apr 17, 2010 at 8:01 AM, patrickk <sehmasch...@gmail.com> wrote: > > haven´t done much testing yet, so this may be a trivial question. > > > here´s my testcase: > > class CostAccountModelTests(TestCase): > > def setUp(self): > > self.account = CostAccount.objects.create(user_id=1) > > def test_account_created(self): > > self.assertEqual(CostAccount.objects.count(), 1) > > > the user-database is empty, so CostAccount.objects.create(user_id=1) > > shouldn´t work (because user is an fk to auth.user). > > I´ve read that exceptions within setUp are considered an error rather > > than a test failure ... but, test_account_created should fail, right? > > The behavior is database-dependent. It depends on whether, and when, the > database enforces referential integrity. > > Neither SQLite nor MySQL with the MyISAM storage engine will raise an error > when you create a record that violates a foreign key constraint, so this > test as coded will pass on those DBs. > > MySQL with the InnoDB engine will do constraint checking immediately when > you attempt to save the record. This test, as coded, will be reported as an > ERROR and the traceback will show that the objects.create() in setUp() > raised an IntegrityError. > > PostgreSQL also does constraint checking, but Django sets it to do deferred > constraint checking. That means the checks are postponed until the > transaction is actually committed. (This is generally a good thing, as it > allows for loading fixtures with arbitrary ordering of interdependent > related models: these currently fail horribly on MySQL/InnoDB.) However, > nothing is actually committed when running under a django.test.TestCase: > this type of test runs the whole test in a single transaction that is rolled > back at the end, which allows for much faster test running. Thus, since the > errant create() is never commited when running as a TestCase, this test as > coded will also succeed pass using PostgreSQL. You can get it to fail under > PostgreSQL by changing it to be a django.test.TransactionTestCase, which > allows for the code under test to issue commits. > > Karen > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
