Comment l'Unité de test avec des paramètres différents dans Django?

Est-il un simple mécanisme de remplacement des Django paramètres d'un test unitaire? J'ai un manager sur un de mes modèles qui renvoie un nombre précis de la dernière objets. Le nombre d'objets qu'elle renvoie est défini par un NUM_LATEST réglage.

Cela a le potentiel pour faire mes tests échouent si quelqu'un venait à changer le réglage. Comment puis-je remplacer les paramètres sur setUp() et par la suite de les restaurer sur tearDown()? Si ce n'est pas possible, est-il une manière que je peux monkey patch de la méthode ou de se moquer de l'paramètres?

EDIT: Voici mon code gestionnaire:

class LatestManager(models.Manager):
    """
    Returns a specific number of the most recent public Articles as defined by 
    the NEWS_LATEST_MAX setting.
    """
    def get_query_set(self):
        num_latest = getattr(settings, 'NEWS_NUM_LATEST', 10)
        return super(LatestManager, self).get_query_set().filter(is_public=True)[:num_latest]

Le gestionnaire utilise settings.NEWS_LATEST_MAX à couper le queryset. Le getattr() est simplement utilisé pour fournir une valeur par défaut si le paramètre n'existe pas.

pouvez-vous expliquer pourquoi ou de fournir une meilleure réponse?
Il a changé dans l'intervalle; l'ancien accepté un a celui-ci 😉

InformationsquelleAutor Soviut | 2009-05-27

143

EDIT: Cette réponse s'applique si vous voulez changer les paramètres d'un petit nombre de spécifiques tests.

Depuis Django 1.4, il existe des moyens pour remplacer les paramètres pendant les essais:
https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings

Cas de test auto.paramètres du gestionnaire de contexte, et il y aura aussi un @override_settings décorateur qui peut être appliqué à une méthode de test ou d'un ensemble de cas de test sous-classe.

Ces caractéristiques n'existent pas encore dans Django 1.3.

Si vous souhaitez modifier les paramètres tous vos tests, vous aurez envie de créer un fichier de paramètres pour le test, qui permet de charger et remplacer les paramètres de votre principal fichier de paramètres. Il y a plusieurs approches dans les autres réponses, j'ai vu des succès des variations sur les deux hspander de l' et dmitrii de l' approches.
- Je dirais que c'est la meilleure façon de le faire maintenant dans Django 1.4+
- Comment avez-vous accès à ce que le réglage de dans les tests? Meilleure que j'ai trouvé est quelque chose comme self.settings().wrapped.MEDIA_ROOT, mais c'est assez terrible.
- Les nouvelles versions de Django ont un gestionnaire de contexte pour ceci: docs.djangoproject.com/en/1.8/topics/testing/tools/...
- Mon préféré: @modify_settings(MIDDLEWARE_CLASSES=... (merci pour cette réponse)
InformationsquelleAutor slinkp
44

Vous pouvez faire ce que vous voulez à la UnitTest sous-classe, y compris l'établissement et la lecture des propriétés d'une instance:
```
from django.conf import settings

class MyTest(unittest.TestCase):
   def setUp(self):
       self.old_setting = settings.NUM_LATEST
       settings.NUM_LATEST = 5 # value tested against in the TestCase

   def tearDown(self):
       settings.NUM_LATEST = self.old_setting
```
Depuis le django des cas de test à exécuter single-threaded, cependant, je suis curieux de savoir ce que l'autre personne peut être en modifiant le NUM_LATEST valeur? Si cette "autre chose" est déclenchée par votre routine de test, alors je ne suis pas sûr de tout montant de monkey patching permettra d'économiser de l'essai sans invalider la véracité des tests de lui-même.
- J'ai ajouté un exemple de code.
- Ah, gotcha... exemple de code efface jusqu'.
- Votre exemple a travaillé. Cela a été une révélation en ce qui concerne la portée de l'unité de test et de la façon dont les paramètres dans les tests de fichier se propager vers le bas à travers la pile d'appel.
- Cela ne fonctionne pas avec settings.TEMPLATE_LOADERS... Donc ce n'est pas façon générale, au moins, les paramètres ou Django n'est pas rechargé ou rien avec ce truc.
- Cela ne fonctionne pas avec les paramètres.La JOURNALISATION
- Il ne fonctionne pas avec USE_TZ 🙁
- c'est un bon exemple pour la version de Django âgés de plus de 1.4. Pour >= 1.4 répondre à stackoverflow.com/a/6415129/190127 plus correct
- Utiliser les docs.djangoproject.com/en/dev/topics/testing/tools/... Patcher avec l'installation et le démontage de ce genre est un excellent moyen de faire vraiment fragile de tests plus bavarde que dont ils ont besoin pour être. Si vous avez besoin de patch quelque chose comme cela, utilisez quelque chose comme flexmock.
- "Depuis le django des cas de test à exécuter single-threaded": qui n'est plus le cas dans Django 1.9.
InformationsquelleAutor Jarret Hardie
20

Mise à jour: la solution ci-dessous n'est nécessaire que sur Django 1.3.x et les versions antérieures. Pour >1.4 voir slinkp réponse.

Si vous modifiez les paramètres fréquemment dans vos tests et l'utilisation de Python ≥2.5, c'est également à portée de main:
```
from contextlib import contextmanager

class SettingDoesNotExist:
    pass

@contextmanager
def patch_settings(**kwargs):
    from django.conf import settings
    old_settings = []
    for key, new_value in kwargs.items():
        old_value = getattr(settings, key, SettingDoesNotExist)
        old_settings.append((key, old_value))
        setattr(settings, key, new_value)
    yield
    for key, old_value in old_settings:
        if old_value is SettingDoesNotExist:
            delattr(settings, key)
        else:
            setattr(settings, key, old_value)
```
Alors vous pouvez faire:
```
with patch_settings(MY_SETTING='my value', OTHER_SETTING='other value'):
    do_my_tests()
```
- C'est vraiment cool solution. Pour une raison quelconque, mes réglages n'ont pas été correctement son travail dans les tests unitaires. Très élégante solution, merci pour le partage.
- Je suis en utilisant ce code, mais j'ai eu des problèmes avec cascade d'échec de test, car les paramètres ne serait pas obtenir de côté si le test en question a échoué. Pour répondre à cela, j'ai ajouté un try/finally autour de la yield déclaration, avec la dernière partie de la fonction contenue dans le finally bloc, de sorte que les paramètres sont toujours revenue.
- Je vais modifier la réponse pour la postérité. J'espère que je suis en train de faire de ce droit! 🙂
InformationsquelleAutor akaihola
17

Vous pouvez passer --settings option lors de l'exécution de tests
```
python manage.py test --settings=mysite.settings_local
```
- il s'est arrêté pour trouver des applications qui sont situés dans les paramètres.dev qui est de l'extension de paramètres.la base de
- Je pense que ça va être dangereux si quelqu'un oublie d'ajouter les paramètres d'une fois.
InformationsquelleAutor MicroPyramid
16

Bien que primordial de configuration des paramètres de l'exécution peut aider, à mon avis, vous devez créer un fichier séparé pour les tests. Cela permet d'économiser beaucoup de la configuration pour le test et cela permettrait de s'assurer que vous ne jamais faire quelque chose d'irréversible (comme le nettoyage de base de données intermédiaire).

Dire que votre test de fichier existe dans 'my_project/test_settings.py', ajouter
```
settings = 'my_project.test_settings' if 'test' in sys.argv else 'my_project.settings'
```
dans votre manage.py. Cela permettra d'assurer que lorsque vous exécutez python manage.py test vous utilisez test_settings seulement. Si vous êtes en utilisant un autre essai de client comme pytest, vous pouvez aussi facilement ajouter à pytest.ini
- Je pense que c'est une bonne solution pour moi. J'ai beaucoup trop de tests et le code qui est à l'aide de cache. Il sera difficile pour moi de remplacer les paramètres un par un. Je vais créer deux fichier de config et de déterminer lequel utiliser. Le MicroPyramid la réponse est également disponible, mais il va être dangereux si j'ai oublié d'ajouter les paramètres d'une fois.
InformationsquelleAutor hspandher
8

@override_settings est idéal si vous n'avez pas beaucoup de différences entre votre production et l'environnement de test configurations.

Dans d'autres cas, vous feriez mieux de juste avoir des paramètres différents fichiers. Dans ce cas, votre projet doit ressembler à cela:
```
your_project
    your_app
        ...
    settings
        __init__.py
        base.py
        dev.py
        test.py
        production.py
    manage.py
```
De sorte que vous devez avoir votre la plupart de vos paramètres de base.py puis dans d'autres fichiers dont vous avez besoin pour importer tous les tout à partir de là, et de modifier certaines options. Voici ce que votre test.py fichier ressemblera à:
```
from .base import *

DEBUG = False

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

PASSWORD_HASHERS = (
    'django.contrib.auth.hashers.MD5PasswordHasher',
)

LOGGING = {}
```
Et ensuite, soit vous devez spécifier --settings option comme dans @MicroPyramid de réponse, ou de spécifier DJANGO_SETTINGS_MODULE variable d'environnement, puis vous pouvez exécuter vos tests:
```
export DJANGO_SETTINGS_MODULE=settings.test
python manage.py test 
```
- Bonjour . Dmitrii, merci pour votre réponse je rencontre le même cas avec cette réponse, mais j'aimerais avoir plus d'indications sur la façon dont l'application sera le savez, l'environnement, nous sommes dans (test ou production), jetez un oeil sur ma branche, découvrez mon repo github.com/andela/ah-backend-iroquois/tree/develop/authors , comme, comment vais-je gérer cette logique ?
- Parce que j'utilise nosetests pour l'exécution des tests , maintenant comment cela va fonctionner?, dans l'environnement de test pas de environnement de développement
InformationsquelleAutor Dmitrii Mikhailov
3

Trouvé cela tout en essayant de résoudre certains doctests... Pour être complet, je tiens à mentionner que si vous allez modifier les paramètres lors de l'utilisation de doctests, vous devez le faire avant d'importer autre chose...
```
>>> from django.conf import settings

>>> settings.SOME_SETTING = 20

>>> # Your other imports
>>> from django.core.paginator import Paginator
>>> # etc
```
InformationsquelleAutor Jiaaro

Je suis en utilisant pytest.

J'ai réussi à résoudre ce la façon suivante:

import django    
import app.setting
import modules.that.use.setting

# do some stuff with default setting
setting.VALUE = "some value"
django.setup()
import importlib
importlib.reload(app.settings)
importlib.reload(modules.that.use.setting)
# do some stuff with settings new value

InformationsquelleAutor Brontes

Vous devez vous connecter pour publier un commentaire.