I am new to Django and following several tutorials. I created a separate app for functional testing. I also setup a postgres DB engine for my prod DBMS but for testing I'd like to use SQLite3 in memory. Could someone tell me how to override the prod DB with another settings.py file? Where would I put the override file, in my functional test app folder? How does Django know which settings to use for prod vs. testing? Any help appreciated, thanks!
As an option:
Create a file names settings_test.py that contains something like:
from settings import * # if your main settings file is settings.py
DATABASES['default']['ENGINE'] = 'django.db.backends.sqlite3'
# and whatever other settings like db name etc.
Then run tests with the settings:
./manage.py test --settings=settings_test
Complementing Dima's answer, you can take a look at:
https://docs.djangoproject.com/en/1.4/internals/contributing/writing-code/unit-tests/#using-another-settings-module
Related
How do I seperate production and development database in Django 1.8?
For now I'm doing the naive way using the same database for both dev and production. When deploying, the dev database are copied over production (SQLite).
What's the correct way to do this in Django 1.8? Additionally, how can I update production tables without losing previous data?
Well, first off, I would really recommend you to not use sqlite in production. If you insist, what I would do would be to make a copy of the sqlite file outside of the project structure, and use an additional settings file for live only, such as settings_live.py and override the DATABASES setting with the correct path:
from myproject.settings import *
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': ..., # the correct path file name here
}
}
Make sure that you specify the correct settings file in your production environment. For example, for wsgi:
os.environ.setdefault('DJANGO_SETTINGS_MODULE', wsgi_app + '.settings_live')
Update
Marina Mele has written a thorough article on the dual environment setup "thing".
In my setup, I have 2 or 3 different virtualenvs.
I also have a main settings.py with the basic parameters and different settings that inherit from the main and cater for each virtualenv.
The idea is described here and here.
In my .virtualenvs/bin/activate file I append the path to the relevant settings file:
DJANGO_SETTINGS_MODULE=air.settings.settingst
export DJANGO_SETTINGS_MODULE
This way, I have a separate database for each environment for the same project.
I have a project and into this project I have different apps.. The problem is, a specific app is another website inside the same project and uses different settings file.
When I run the tests separated, it works perfectly, when I try to run all tests together, the app which uses a different settings file fails..
Any idea how to fix it?
I tried to override the settings into setUp method as below:
for s in dir(settings_appA):
if getattr(settings, s) == None:
setattr(settings, s, getattr(settings_appA, s))
When I do it, works for the specific website but not for other apps..
Any idea?
./manage.py test <app1> --settings=settings1
./manage.py test <app2> --settings=settings2
I would like to test my small application, that I keep in a separate package. Right now I created a "test_project" directory, created a test project there and I am using the project's manage.py to run tests. But I keep wondering - is there a better method? Is it possible to launch a single app's tests, perhaps with some default configuration (like, sqlite database)?
It is possible to run a single app's tests standalone, without creating a Django test project for that purpose. One way of doing so is by creating a runtests.py in your app's root dir which setups Django settings and runs ./manage.py test your_app programmatically. One example of runtests.py is Django's own: runtests.py (documentation).
Django's own runtests.py is a good reference but I find it convoluted for most cases. Below are a couple of alternative examples:
Django-Modeltranslation
My own minimalistic one
Writing this down because I don't see it on here yet
From the docs
If your django structure looks something like this as it should:
Project dir/
/myapp
/myotherapp
/myproject
Django allows you to execute test from only "myotherapp" by executing:
./manage.py test myotherapp/
This will execute all test under "myotherapp" whereas
./manage.py test
will execute all test in your projects directory.
If you use nose you can run a single app's tests.
python manage.py test app.tests:TestClassHere
as for testing a single app. I just follow the convention other big django projects do, and that is exactly what you are doing. Create a test_project directory.
https://github.com/mozilla/django-piston/tree/master/tests/test_project
I figure if it is good enough for some of the biggest django pluggable apps it's good enough for me.
Ofcourse you can test the Python parts with a standalone unittest if you don't need any django dependencies
A Django environment requires atleast a settings.py and manage.py file. You can setup those with essential stuff only and UnitTest your app with manage.py. You should see a project as a Django runtime environment, there's no Django without it. You can probably mimic settings but tbh you would just be creating more hacks than simplicity.
You can also create a custom test runner and override the path it searches for tests in.
Perhaps I buried the lede here. I recently inherited a project that had legacy tests they wanted to keep for historical reasons, so I was forced to write all my tests in one folder and point to it
from django.test.runner import DiscoverRunner
class MyTestRunner(DiscoverRunner):
def __init__(self, *args, **kwargs):
kwargs.update({'top_level': str(settings.TEST_DISCOVER_TOP_LEVEL)})
super().__init__(*args, **kwargs)
def run_tests(self, test_labels, extra_tests=None, **kwargs):
# In order to override the top_level directory, the test_label must match the top_level
kwargs.update({'test_labels': [str(settings.TEST_DISCOVER_TOP_LEVEL)]})
return super().run_tests(extra_tests=extra_tests, **kwargs)
and in your settings
TEST_RUNNER = 'path.to.my.module.MyTestRunner'
TEST_DISCOVER_TOP_LEVEL = BASE_DIR / 'tests/unit_and_integration_tests'
I'm new to Git. I need to setup Git to deploy a Django website to the production server. My question here is to know what is the best way of doing this.
By now I only have a Master branch. My problem here is that Development environment is not equal to the Production environment. How can I have the two environments(Development and Production) in Git? Should I use two new Branches(Development and Production). Please give me a clue on this.
Other question... when I finish to upload/push the code to the Production server I need to restart the Gunicorn(serves Django website). How can I do this?
And the most important question... Should I use Git to do this or I have better options?
Best Regards,
The first question you must solve is your project structure. Usually the difference between development and the production environment is setting.py and url.py. So why you firstly separate those? :) For example you can have one main settings.py where you define all the default settings which are in common. Then at the end of the file you just import the settings_dev.py and settting_prod.py for exemple:
try:
from settings_prod import *
except ImportError:
pass
try:
from settings_dev import *
except ImportError:
pass
Then simply you can overload all the setting you want and have custom settings of the project (for example installed apps). The same logic you can use for urls.py file.
Then you can simply ignore adding the *_dev files to repo and on the server side you can just checkout the code from repo and restart http server. To automatize this for now I can't give the right name of app to use. Sometimes simple python script could be solution like: watching if the file datetime changed and if yes, just run restart command for http.
Hope that helped.
Ignas
You can follow this brunching model - http://nvie.com/posts/a-successful-git-branching-model/
And, git is ok but use Fabric for deployment.
I use Postgres for production and development, but I'd like to use sqlite to run some tests. I don't see an easy way to configure one engine for tests and another for dev / production. Am I missing something?
Append the following lines in your settings:
import sys
if 'test' in sys.argv or 'test_coverage' in sys.argv: #Covers regular testing and django-coverage
DATABASES['default']['ENGINE'] = 'django.db.backends.sqlite3'
Make sure your actual database setting comes before them.
This is not a direct answer, but yes, you are missing one big problem - testing a Postgres app on SQLite is tricky - they are so different. I suggest you rather create a ram-disk (e.g. using tmpfs) and create your Postgres test database there. It won't be as fast as SQLite, but possibly an order of magnitude faster than regular Postgres database stored on HDD.
You could try a setup similar to what is suggested here by Zachary Voase:
http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/
(The entire post is useful, but scroll down to the section on "Settings" for the part most relevant here.)
Zach's strategy is to create a settings folder and marks it as a python package using a __init__.py file. You can then have a separate sub-module for each of your deployment types, structured as follows:
settings/
|-- __init__.py # Empty; makes this a Python package
|-- common.py # All the common settings are defined here
|-- development.py # Settings for development
|-- production.py # Settings for production
|-- staging.py # Settings for staging
Following this concept, you could set up a deployment for postgres and a separate deployment for sqlite, and separate the configurations for each as needed.
I think modifying the settings.py with if 'test' in sys.argv as suggested is a hack and doesn't work for example when you want multi-threaded test execution in pytest.
I think a better way would be to create a separate settings_test.py and adding
DATABASES['default']['ENGINE'] = 'django.db.backends.sqlite3' to it.
When using Django's testframework, execute your tests with python manage.py test --settings=myapp.settings_test
When using pytest, create a pytest.ini and insert
[pytest]
DJANGO_SETTINGS_MODULE = myapp.settings_test
I've end up by adding the following in my settings.py.
The --keepdb will setup the Sqlite DB in RAM.
if 'test' in sys.argv:
for db_test in ['default']: # Add other DBs if needed
DATABASES[db_test]['ENGINE'] = 'django.db.backends.sqlite3'
if '--keepdb' in sys.argv:
DATABASES[db_test]['TEST']['NAME'] = '/dev/shm/' + db_test + '.test.db.sqlite3'