2012-08-27 21 views
12

Tengo un modelo con un ImageField que está respaldado por django-storage's 'S3Boto. Tengo una prueba en los ejercicios de la vista "cargar imagen", pero el hecho de que esté cargando la imagen a S3 está ralentizando mi conjunto de pruebas.Mocking Django Storages Model ImageField backend S3

En aras de acelerar mis pruebas, ¿cuál es la mejor práctica para tratar este problema? ¿Debería burlarme de S3Boto? Tal vez haya un backend de almacenamiento con respaldo de memoria que funcione bien para las pruebas (¡la limpieza automática sería agradable!)?

Respuesta

7

Acabo de tener este problema también. Obtuve pruebas mucho más rápidas usando dj-inmemorystorage.

La forma más rápida de configurar esto es mediante la creación de un test_settings.py en la misma carpeta que la configuración:

from settings import * 
DEFAULT_FILE_STORAGE = 'inmemorystorage.InMemoryStorage' 

... ./manage.py test --settings=project.test_settings y llamando a ejecutar las pruebas.

Mi forma preferida es la creación de un corredor de prueba personalizada:

En project/test_runner.py:

from django.conf import settings 
from django.test.runner import DiscoverRunner 

class FastTestRunner(DiscoverRunner): 
    def setup_test_environment(self): 
     super(FastTestRunner, self).setup_test_environment() 
     # Don't write files 
     settings.DEFAULT_FILE_STORAGE = 'inmemorystorage.InMemoryStorage' 
     # Bonus: Use a faster password hasher. This REALLY helps. 
     settings.PASSWORD_HASHERS = (
      'django.contrib.auth.hashers.MD5PasswordHasher', 
     ) 

Nota: Esto también establece el PASSWORD_HASHER, porque significantly improves User creation time. Esto NO se debe establecer en producción.

En project/settings.py:

TEST_RUNNER = 'project.test_runner.FastTestRunner' 

Los requisitos:

pip install dj-inmemorystorage 

ACTUALIZACIÓN: cambiado de django-inmemorystorage a dj-inmemorystorage.

ACTUALIZACIÓN 2: Se eliminó django-discover-runner, ya que ahora es el corredor de prueba predeterminado en django, y se corrigió el enlace a la publicación de blog relacionada PASSWORD_HASHER.

0

Propongo utilizar el almacenamiento Django estándar para la prueba, donde puede definir una ruta personalizada para el almacenamiento y la limpieza de esa ruta en su suite de prueba una vez que haya terminado. Tanto el almacenamiento como la ruta se pueden configurar en la configuración y sobrescribir para la prueba.

+1

Debería haber mencionado anteriormente, estoy usando una clase de Almacenamiento personalizada y configurándola solo para este modelo en el campo: modelos .FileField (storage = CustomS3Storage (...)) - así que intercambiando la configuración ganada Realmente funciona – erikcw

+0

@erikcw: aún puede sobrescribir el almacenamiento de FileField de su modelo en la configuración de TestCase (o en el nivel de módulo de prueba, etc.). –

1

Acabo de toparme con esto también así que pensé en poner mi solución. Mi solución utiliza Mock

import mock 
from django.core.files.storage import FileSystemStorage 
from django.test import TestCase 

class ATestCase(TestCase): 
    def setUp(self): 
     # Stuff Happens 

    def tearDown(self): 
     # more Stuff 

    @mock.patch('storages.backends.s3boto.S3BotoStorage', FileSystemStorage) 
    def test_file_stuff(self): 
     self.assertMagicPonies(True) 

también algunas precauciones - asegurarse de que tiene una configuración de cuerdo MEDIA_ROOT en la configuración. a partir de django 1.4, no puede usar el administrador de contexto de prueba para anular MEDIA_ROOT, por lo que necesita una configuración de configuración separada para él ( https://code.djangoproject.com/ticket/17787) Esto se arregló en 1.6. Además, asegúrese de que su upload_to funcione en el sistema de archivos normal, o obtendrá errores de permiso.

+0

esto no funciona para mí, el almacenamiento en FileField todavía se establece en la definición original, no FileSystemStorage – Peyman

Cuestiones relacionadas