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.

Reply via email to