Re: Tests and read-only database

[Tom Evans]

On Tue, Feb 10, 2015 at 1:29 AM, Scot Hacker  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.

Re: Tests and read-only database

[Scot Hacker]

On Tuesday, February 10, 2015 at 12:55:57 AM UTC-8, Avraham Serour wrote:
>
> you can tell django to use sqlite for tests, it will create an in memory 
> sqlite
>

Thanks Avraham. Having a bit of trouble finding specifics on this in the 
documentation, but this works neatly:

if 'test' in sys.argv or 'test_coverage' in sys.argv:  # Covers regular 
testing and django-coverage
DATABASES['default']['ENGINE'] = 'django.db.backends.sqlite3'
DATABASES['tmi']['ENGINE'] = 'django.db.backends.sqlite3' 

Nice speed improvement with those in-memory dbs, too! 

./s

-- 
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/71da6c8c-69ce-4a76-96b5-624be72771cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests and read-only database

[Avraham Serour]

you can tell django to use sqlite for tests, it will create an in memory
sqlite

if you need the data on the DB for the tests you can import when
initializing the tests, dump a part of the data and call it test data

On Tue, Feb 10, 2015 at 3:29 AM, Scot Hacker  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.
>
>  --
> 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/2d599e4b-d208-472f-9a62-fc9c187da1d1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAFWa6tLbcpXps87WB9RsFyRmDLZf5F3eL-LwsHyni1duZxEnpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Tests and read-only database

[Scot Hacker]

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.

-- 
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/2d599e4b-d208-472f-9a62-fc9c187da1d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.