2009-12-19 8 views
7

No puedo acceder al atributo context de un objeto HttpResponse de ipython. Pero la unidad de prueba tiene acceso a context.Django: el contexto del cliente de prueba está vacío desde el shell

Aquí está la prueba de la unidad. La prueba de funcionamiento pasa correctamente:

from django.test import Client, TestCase 
from django.core import mail 

class ClientTest(TestCase): 
    def test_get_view(self): 
     data = {'var': u'\xf2'} 
     response = self.client.get('/test04/', data) 

     # Check some response details 
     self.assertContains(response, 'This is a test') 
     self.assertEqual(response.context['var'], u'\xf2') 

Aquí está el código que he utilizado en el shell:

In [10]: from django.test import Client 

In [11]: c = Client() 

In [12]: r = c.get('/test04/', data) 

In [13]: r.context 

In [14]: type(r.context) 
Out[14]: <type 'NoneType'> 

response.context hay ninguno en la carcasa mientras que response.context existe en la unidad de prueba.

¿Por qué HttpResponse se comporta de manera incoherente entre el shell y la prueba unitaria?

+0

Lo intenté yo mismo y ni el contexto ni la plantilla están configurados en el shell de Django. Supongo que el Cliente no está destinado a ser utilizado en un shell interactivo. El corredor de prueba hace algunos instrumentos antes de ejecutar las pruebas, que no se activarán a través del shell. Ver 'django.test.testcases' – muhuk

Respuesta

6

Puede ver en el código de prueba de Django donde aparece el parche en instrumentación especial en make template rendering send a signal, que es test client listens to, por lo que puede annotate the response object with the rendered templates and their contexts.

Para que esta señal se adjunte, debe llamar a la función django.test.utils.setup_test_environment() en su sesión de shell (que tiene otros efectos secundarios) o duplicar solo las líneas que representan la plantilla de monopapeles . No es demasiado difícil, pero estoy de acuerdo en que sería bueno si este aspecto de depuración en particular pudiera ser refactorizado para que sea más fácil de usar fuera de las pruebas. Personalmente, no me importaría si esta información siempre se recopilara cuando DEBUG sea Verdadero, no solo bajo prueba.

Cuestiones relacionadas