Malcolm Tredinnick wrote: > On Mon, 2007-07-02 at 16:21 +0200, Lars Stavholm wrote: >> Hi All, >> >> I'm trying to build an rpm package for django, both stable (0.96) >> and svn trunk. In the process I want to verify/test the installation >> using the runtests.py in the tests subdirectory. It all seems to work >> OK, but I get regression test failures that I'm not sure about. >> >> My settings.py looks like this: >> DATABASE_NAME = None >> DATABASE_ENGINE = 'sqlite3' >> DATABASE_USER = None >> DATABASE_PASSWORD = None >> ROOT_URLCONF = None >> SITE_ID = 0 >> >> First of all: where is the test database created? > > For sqlite, the test database is in-memory (search for ":memory:"). For > other backends, it's called django_test-db, although this can be changed > in the settings file, so search for TEST_DATABASE_NAME if you are > looking for where it is used in the code.
Ah, in memory, of course, forgot that sqlite could do that. >> Can't seem to find it during the tests, looked for >> django_test_db. >> >> On 0.96 stable I get two failures: > [...] >> And similar for svn trunk (revision 5584 as of Sun Jul 1 2007, >> and revision 5582 of the same date) but this time only one error: >> >> % cd django-svn-0.97-5584/tests >> % ./runtests.py --settings=settings -v 1 >> [snip] >> Loading 'initial_data' fixtures... >> Installing json fixture 'initial_data' from >> '/home/stava/proj/addons/django-svn/django-svn-0.97-5584/tests/modeltests/fixtures/fixtures'. >> Installed 1 object(s) from 1 fixture(s) >> .............................................................E......................................................................... >> ====================================================================== >> ERROR: Request a page that is protected with @login_required >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/stava/proj/addons/django-svn/django-svn-0.97-5584/tests/modeltests/test_client/models.py", >> line 211, in test_view_with_login >> self.assertRedirects(response, '/accounts/login/') >> File "/usr/lib/python2.5/site-packages/django/test/testcases.py", line >> 71, in assertRedirects >> redirect_response = self.client.get(path) >> File "/usr/lib/python2.5/site-packages/django/test/client.py", line >> 200, in get >> return self.request(**r) >> File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py", >> line 77, in get_response >> response = callback(request, *callback_args, **callback_kwargs) >> File "/usr/lib/python2.5/site-packages/django/contrib/auth/views.py", >> line 32, in login >> 'site_name': Site.objects.get_current().name, >> File >> "/usr/lib/python2.5/site-packages/django/contrib/sites/models.py", line >> 7, in get_current >> return self.get(pk=settings.SITE_ID) >> File "/usr/lib/python2.5/site-packages/django/db/models/manager.py", >> line 73, in get >> return self.get_query_set().get(*args, **kwargs) >> File "/usr/lib/python2.5/site-packages/django/db/models/query.py", >> line 261, in get >> raise self.model.DoesNotExist, "%s matching query does not exist." % >> self.model._meta.object_name >> DoesNotExist: Site matching query does not exist. >> ---------------------------------------------------------------------- >> Ran 135 tests in 166.710s >> FAILED (errors=1) >> Destroying test database... >> >> So, is it something missing in my environment >> or the way I run the tests or what? > > Whoops; you've found a subtle bug -- not sure if it's a code bug or a > documentation bug yet. Change your SITE_ID value to be something other > than 0 and the tests will pass, at least for the latter case. > Embarrassingly, I don't have a clean 0.96 tarball lying around, so I > haven't checked that case. I set SITE_ID = 1 and ran both tests again, this time with no failures at all. > Somewhere we're doing something like "if settings.SITE_ID" or "if val" > where val is settings.SITE_ID and failing because 0 == False. That might > or might not be easy to work around (or find). It could be that we end > up having to say SITE_ID must be nonzero,, but that's certainly the > workaround for now. The devil's in the details:) If nothing else, the doco should be updated, I've filed a ticket (#4745). Thanks for your help Malcolm! /Lars Stavholm (http://linadd.org) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
