Une autre base de données pour tester à Django?

Question

 DATABASES = {
#    'default': {
#        'ENGINE': 'postgresql_psycopg2',
#        ...
#    }

    # for unit tests
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'mydatabase'
    }
}
 

J'ai deux bases de données: une que j'aimerais utiliser pour les tests unitaires et une pour tout le reste. Est-il possible de configurer cela dans Django 1.2.4?

(La raison pour laquelle je pose cette question est parce qu'avec postgresql, l'erreur suivante apparaît:

 foo@bar:~/path/$ python manage.py test
Creating test database 'default'...
Got an error creating the test database: permission denied to create database

Type 'yes' if you would like to try deleting the test database 'test_baz', or 'no' to cancel: yes
Destroying old test database...
Got an error recreating the test database: database "test_baz" does not exist
 

Pourquoi pourrais-je avoir cette erreur? Je suppose que je ne me soucie pas vraiment de pouvoir toujours utiliser SQLite pour les tests unitaires, car cela fonctionne bien.)

Answer 1

Dans votre settings.py (ou local_settings.py ):

 import sys
if 'test' in sys.argv:
    DATABASES['default'] = {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'mydatabase'
    }
 

Answer 2

La façon dont je le manipuler, c'est par le fait d'avoir plusieurs fichiers de paramètres, depuis que j'utilise que pour maintenir un ensemble de paramètres communs avec des modifications pour chaque instance. C'est un peu plus compliquée à mettre en place que d'autres solutions, mais je devais le faire de toute façon parce que j'ai été légèrement la gestion des paramètres différents pour le développement local, distant de développement, de production et de transfert.

https://code.djangoproject.com/wiki/SplitSettings a un certain nombre d'options pour la gestion des paramètres, et j'ai choisi une pratique analogue à celle décrite à https://code.djangoproject.com/wiki/SplitSettings#SimplePackageOrganizationforEnvironments

Donc, dans mon projet Django répertoire, j'ai un dossier paramètres qui ressemble à ceci:

$ tree settings
settings
├── defaults.py
├── dev.py
├── dev.pyc
├── __init__.py
├── lettuce.py
├── travis.py
├── unittest.py

Les paramètres communs sont en settings/defaults.py et je les importer dans mon exemple des fichiers de paramètres. Donc settings/unittest.py ressemble à ceci:

from defaults import *

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'my_database',
    }
} 

Ensuite, quand je veux exécuter des tests, je viens d'exécuter:

$ ./manage.py test --settings=settings.unittest

pour l'utilisation de sqlite pour les tests. Je vais utiliser un autre module paramètres si je veux utiliser un autre test runner ou de la base de données de configuration.

Answer 3

Si cela est déjà résolu...

Si votre base de données pour les tests est juste un type normal DB:

Je pense que vous ne faites pas de test de l'unité puisque vous compter dans la base de données. De toute façon, django contient un type de test que (non unitaire): django.test.TestCase

Vous avez besoin de dériver de l' django.test.TestCase au lieu de unittest.TestCase qui permettra de créer une nouvelle rehershal base de données pour vous qui sera détruit lors de la fin d'essai.

Il y a des explications/conseils sur les tests avec la db dans le lien suivant
Les Tests De Django Applications

Answer 4

Si vous avez accès à créer manuellement la base de données, vous pouvez utiliser django-nez que votre TEST_RUNNER. Une fois installé, si vous passez par la variable d'environnement suivante, il ne sera pas supprimer et de re-créer la base de données.

REUSE_DB=1 ./manage.py test

Vous pouvez également ajouter ce qui suit à settings.py si vous n'avez pas à écrire REUSE_DB=1 chaque fois que vous voulez exécuter des tests:

os.environ['REUSE_DB'] = "1"

Remarque: cela permettra également de laisser toutes vos tables dans les bases de données ce qui signifie l'installation d'essai sera un peu plus rapide, mais vous devrez mettre à jour manuellement les tables (ou de les supprimer et de re-créer la base de données vous-même) lorsque vous changez vos modèles.