Testing framework or model save behaves differently after qsrf merge?

2 views
Skip to first unread message

peschler

unread,
Jun 9, 2008, 6:53:14 PM6/9/08
to Django users
I'm currently facing a weird problem with the testing framework after
updating to the latest trunk version of the newforms-admin branch. I
have written a small example and a unittest to explain the issue and
to show that there seems to be some sort of problem after the qsrf
merge. I'm not quite sure where the problem is - unittest or qsrf -
that's why i post.

Below are two simple models Vocabulary and Term. A vocabulary contains
terms. When a new vocabulary is created (saved the first time), it
automatically creates a root term for the vocabulary.
Both models overload the save() method.

Running the unittest given below with django 0.97-newforms-admin-
SVN-7233 all tests pass fine.

When running the unittest given below with django 0.97-newforms-admin-
SVN-7599 the tests give the following error:

======================================================================
FAIL: test_qsrf (nmy.qsrftest.tests.QsrfTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/peter/src/nmy/site-packages/nmy/qsrftest/tests.py", line
27, in test_qsrf
self.failUnlessEqual(v.root, v.root.vocabulary.root)
AssertionError: <Term: Term object> != None

----------------------------------------------------------------------

I tried to track down the problem, checked my unittest, checked my
models - but the only thing I could find is weird: As soon as I
reference the ``vocabulary`` field in a term's save() method the test
fails. If I remove all references to the ``vocabulary`` field from the
save() method the tests pass fine.
I found that a simple read-only operation like print or even a simple
noop reference of the ``vocabulary`` field changes the behaviour of
the unittest.

--- qsrftest/models.py
from django.db import models

class Vocabulary(models.Model):
root = models.ForeignKey('Term', null=True, blank=True,
related_name='root_of')

def save(self):
"""When a vocabulary is saved and it has no root term, a new
root
term is created. This happens only the first time a vocabulary
is
saved.
"""
super(Vocabulary, self).save()

if not self.root:
self.root = Term.objects.create(vocabulary=self)
super(Vocabulary, self).save()

class Term(models.Model):
vocabulary = models.ForeignKey(Vocabulary)

def save(self):
super(Term, self).save()

# As soon as self.vocabulary is referenced here, the unittest
fails.
# It does not matter if the self.vocabulary is printed, used
or changed.
# Any of the following will make the unittest fail with
r7599!
#print "term.vocabulary:", self.vocabulary
self.vocabulary

---
--- qsrftest/tests.py
import unittest

from qsrftest.models import Vocabulary, Term

class QsrfTestCase(unittest.TestCase):

def test_qsrf(self):
v = Vocabulary.objects.create()

# Check if the new vocabulary has a root term
self.failUnless(v.root != None,
'A newly created vocabulary must have a root
term.')

# Check that the root item is associated to the vocabulary.
self.failUnlessEqual(v, v.root.vocabulary,
'The vocabulary of the implicity created root
term must'\
'be set. %s != %s'\
% (v, v.root.vocabulary))

# Check cyclic correctness. This test succeeds with r7433 and
fails
# with r7599 when the ``vocabulary`` field is referenced in
the
# term's save() method.
self.failUnlessEqual(v.root, v.root.vocabulary.root)
---

Russell Keith-Magee

unread,
Jun 10, 2008, 9:45:54 AM6/10/08
to django...@googlegroups.com
On Tue, Jun 10, 2008 at 6:53 AM, peschler <pesc...@googlemail.com> wrote:
>
> I'm currently facing a weird problem with the testing framework after
> updating to the latest trunk version of the newforms-admin branch. I
> have written a small example and a unittest to explain the issue and
> to show that there seems to be some sort of problem after the qsrf
> merge. I'm not quite sure where the problem is - unittest or qsrf -
> that's why i post.

I can't see anything obviously wrong with your usage here. Given that
you have a reproducable test case, your best bet is to open a ticket.
This is the best way to make sure the issue isn't lost in the bottom
of somebody's inbox. We might not be able to look at it _right now_,
but as long as there is a ticket, it will get looked at eventually.

Yours,
Russ Magee %-)

peschler

unread,
Jun 11, 2008, 9:50:42 AM6/11/08
to Django users
Hi Russ,

thanks for your answer. I will open a ticket and attach the test case.

regards,
peschler

On 10 Jun., 15:45, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:
Reply all
Reply to author
Forward
0 new messages