On Tue, Feb 10, 2015 at 1:29 AM, Scot Hacker <scot.hac...@gmail.com> wrote:
> My project access two databases, one of which is remote and read-only. When
> running tests, Django wants to create a test_ copy of that db on the remote
> host, but of course it lacks permission (I lack write access to the entire
> db host). So I'm blocked from running *any* tests, even ones that don't
> involve models for the remote data.
>
> I've come up with four possible solutions:
>
> 1) Tell Django's test runner to create the test version of that db locally,
> not on the remote host. However, the documentation doesn't indicate a way to
> use the TEST: {} dictionary to specify an alternate host. This would be my
> preferred approach, but it doesn't seem possible.
>
> 2) Use this module, which tells the test runner to treat the read-only db
> "as-is" rather than creating a copy of it. I don't like this because of the
> risk that the db might one day NOT be read-only (it's been discussed in our
> org). And the module is 3 years old without updates.
>
> 3) Use this technique, where the read-only db is pop()'d off the settings,
> making Django effectively forget it exists during testing (but then of
> course I can't test any code that involves those models). I'm currently
> doing this just to get tests back on the rails, but it's obviously very
> limiting.
>
> 4) Use this technique, which alters the routers configuration during
> testing.
>
> Is there a preferred or recommended approach to this problem?
>
> Thanks.
>
5) Use a different settings module for running tests
python manage.py test --settings=project.settings.tests
Having separate configuration files for test allows you to have more
easily repeatable tests, very useful with multi person teams.
We use a structure like so:
manage.py
an_app/
project/
└── settings
├── ci.py
├── defaults.py
├── devs
│ ├── dick.py
│ ├── harry.py
│ └── tom.py
└── www.py
Anyone can then run "python manage.py jenkins
--settings=project.settings.ci" to see exactly what CI (in our case
jenkins) will think of their pending commit. It also makes it
considerably easier in development to override things, eg in my
settings file I might have:
from ..defaults import *
DEBUG = True
INSTALLED_APPS = list(INSTALLED_APPS) + [ 'debug_toolbar', ]
Depending on how your settings are structured currently, you might
need to move some things around and possibly update your manage.py and
wsgi.py to indicate a new default settings module.
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAFHbX1%2BASL0Y43J6aQpCWrm5B6rPPiKwiDkT1ryq8u2%3DepMbNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
