¿Cómo realizar una prueba unitaria con diferentes configuraciones en Django?

¿Existe algún mecanismo simple para anular la configuración de Django para una prueba unitaria? Tengo un administrador en uno de mis modelos que devuelve un número específico de los últimos objetos. El número de objetos que devuelve se define mediante una configuración NUM_LATEST.

Esto tiene el potencial de hacer que mis pruebas fallen si alguien cambia la configuración. ¿Cómo puedo anular la configuración setUp()y luego restaurarla tearDown()? Si eso no es posible, ¿hay alguna forma de que pueda modificar el método o simular la configuración?

EDITAR: Aquí está mi código de administrador:

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]

El administrador utiliza settings.NEWS_LATEST_MAXpara dividir el conjunto de consultas. Se getattr()utiliza simplemente para proporcionar un valor predeterminado en caso de que la configuración no exista.

EDITAR: esta respuesta se aplica si desea cambiar la configuración de una pequeña cantidad de pruebas específicas .

Desde Django 1.4, hay formas de anular la configuración durante las pruebas: https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings

TestCase tendrá un administrador de contexto self.settings, y también habrá un decorador @override_settings que se puede aplicar a un método de prueba o una subclase completa de TestCase.

Estas características aún no existían en Django 1.3.

Si desea cambiar la configuración de todas sus pruebas, querrá crear un archivo de configuración separado para la prueba, que puede cargar y anular la configuración de su archivo de configuración principal. Hay varios buenos enfoques para esto en las otras respuestas; He visto variaciones exitosas en los enfoques de hspander y dmitrii .

Puede hacer lo que quiera con la UnitTestsubclase, incluida la configuración y lectura de las propiedades de la instancia:

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

Sin embargo, dado que los casos de prueba de django se ejecutan en un solo subproceso, tengo curiosidad por saber qué más puede estar modificando el valor NUM_LATEST. Si esa "otra cosa" es activada por su rutina de prueba, entonces no estoy seguro de que cualquier cantidad de parches de mono salvará la prueba sin invalidar la veracidad de las pruebas en sí.

Aunque anular la configuración de la configuración en tiempo de ejecución puede ayudar, en mi opinión, debería crear un archivo separado para probar. Esto ahorra mucha configuración para las pruebas y esto aseguraría que nunca termine haciendo algo irreversible (como limpiar la base de datos provisional).

Digamos que su archivo de prueba existe en 'my_project / test_settings.py', agregue

settings = 'my_project.test_settings' if 'test' in sys.argv else 'my_project.settings'

en su manage.py. Esto asegurará que cuando ejecute python manage.py testuse test_settings solamente. Si está utilizando algún otro cliente de prueba como pytest, podría agregarlo fácilmente a pytest.ini

Puede pasar la --settingsopción al realizar pruebas

python manage.py test --settings=mysite.settings_local

Actualización : la siguiente solución solo es necesaria en Django 1.3.xy versiones anteriores. Para> 1.4, vea la respuesta de slinkp .

Si cambia la configuración con frecuencia en sus pruebas y usa Python ≥2.5, esto también es útil:

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)

Entonces puedes hacer:

with patch_settings(MY_SETTING='my value', OTHER_SETTING='other value'):
    do_my_tests()

@override_settings es excelente si no tiene muchas diferencias entre las configuraciones de su entorno de producción y de prueba.

En otro caso, será mejor que tenga diferentes archivos de configuración. En este caso, su proyecto se verá así:

your_project
    your_app
        ...
    settings
        __init__.py
        base.py
        dev.py
        test.py
        production.py
    manage.py

Por lo tanto, debe tener la mayor parte de su configuración base.pyy luego en otros archivos, debe importar todo desde allí y anular algunas opciones. Así es como test.pyse verá su archivo:

from .base import *

DEBUG = False

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

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

LOGGING = {}

Y luego debe especificar la --settingsopción como en la respuesta de @MicroPyramid, o especificar DJANGO_SETTINGS_MODULEla variable de entorno y luego puede ejecutar sus pruebas:

export DJANGO_SETTINGS_MODULE=settings.test
python manage.py test 

Encontré esto mientras intentaba arreglar algunas pruebas de documentación ... Para completar, quiero mencionar que si va a modificar la configuración al usar pruebas de documentación, debe hacerlo antes de importar cualquier otra cosa ...

>>> from django.conf import settings

>>> settings.SOME_SETTING = 20

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

Para usuarios de Pytest .

El mayor problema es:

• override_settings no funciona con pytest.
• Subclasificar Django TestCaselo hará funcionar, pero luego no puede usar los accesorios de pytest.

La solución es utilizar el settingsaccesorio documentado aquí .

Ejemplo

def test_with_specific_settings(settings):
    settings.DEBUG = False
    settings.MIDDLEWARE = []
    ..

Y en caso de que necesite actualizar varios campos

def override_settings(settings, kwargs):
    for k, v in kwargs.items():
        setattr(settings, k, v)


new_settings = dict(
    DEBUG=True,
    INSTALLED_APPS=[],
)


def test_with_specific_settings(settings):
    override_settings(settings, new_settings)

Puede anular la configuración incluso para una única función de prueba.

from django.test import TestCase, override_settings

class SomeTestCase(TestCase):

    @override_settings(SOME_SETTING="some_value")
    def test_some_function():
        

o puede anular la configuración de cada función en la clase.

@override_settings(SOME_SETTING="some_value")
class SomeTestCase(TestCase):

    def test_some_function():
        

Estoy usando pytest.

Logré resolver esto de la siguiente manera:

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

Puede anular la configuración en la prueba de esta manera:

from django.test import TestCase, override_settings

test_settings = override_settings(
    DEFAULT_FILE_STORAGE='django.core.files.storage.FileSystemStorage',
    PASSWORD_HASHERS=(
        'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
    )
)


@test_settings
class SomeTestCase(TestCase):
    """Your test cases in this class"""

Y si necesita estas mismas configuraciones en otro archivo, puede importarlas directamente test_settings.

Si tiene varios archivos de prueba colocados en un subdirectorio (paquete de Python), puede anular la configuración de todos estos archivos en función de la condición de presencia de la cadena de 'prueba' en sys.argv

app
  tests
    __init__.py
    test_forms.py
    test_models.py

__init__.py:

import sys
from project import settings

if 'test' in sys.argv:
    NEW_SETTINGS = {
        'setting_name': value,
        'another_setting_name': another_value
    }
    settings.__dict__.update(NEW_SETTINGS)

No es el mejor enfoque. Lo usé para cambiar el corredor de apio de Redis a Memory.

Creé un nuevo archivo settings_test.py que importaría todo del archivo settings.py y modificaría lo que sea diferente para fines de prueba. En mi caso, quería usar un depósito de almacenamiento en la nube diferente al realizar la prueba.

settings_test.py:

from project1.settings import *
import os

CLOUD_STORAGE_BUCKET = 'bucket_name_for_testing'

manage.py:

def main():

    # use seperate settings.py for tests
    if 'test' in sys.argv:
        print('using settings_test.py')
        os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project1.settings_test')
    else:
        os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project1.settings')

    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)