Estoy tratando de cambiar de usar Django Test Client a RequestFactory para acelerar mis pruebas. Sin embargo, las solicitudes generadas por RequestFactory no proporcionan los kwargs adecuados a las vistas.
Ejemplo: esta es mi vista
class SomeView(View): def get(self, request, *args, **kwargs): return JsonResponse({'your kwargs': str(kwargs)})con urlconf
url(r'^some_view/(?P<some_kwarg>[\-0-9a-fA-F]+)/$', views.SomeView.as_view(), name='some_view'),y dos pruebas:
def test_different_kwargs(): c = Client() response = c.get( reverse('bots:some_view', kwargs={'some_kwarg': '12345'}), ) print('\n\nResponse for TestClient: ', response.content.decode()) rf = RequestFactory() request = rf.get( reverse('bots:some_view', kwargs={'some_kwarg': '12345'}), ) response = SomeView.as_view()(request) print('\n\nResponse for RequestFactory: ', response.content.decode())Lo que producen es:
Response for TestClient: {"your kwargs": "{'some_kwarg': '12345'}"} Response for RequestFactory: {"your kwargs": "{}"} Entonces, ¿cuál es el punto de RequestFactory si pierde url kwargs? ¿O hay alguna manera de ponerlos en la vista de alguna manera?
EDITAR 2020-03-07: A medida que adquirí más experiencia en pruebas, actualicé mi respuesta para eliminar la confusión sobre las pruebas funcionales y agregué algunos consejos.
Hay dos aspectos en su respuesta.
Respuesta rápida: ¿cómo poner los kwargs en la vista? Necesitas cambiar tu código a esto:
def test_different_kwargs(): kwargs={'some_kwarg': '12345'} url = reverse('bots:some_view', kwargs=kwargs) c = Client() response = c.get(url) print('\n\nResponse for TestClient: ', response.content.decode()) rf = RequestFactory() request = rf.get(url) response = SomeView.as_view()(request, **kwargs) print('\n\nResponse for RequestFactory: ', response.content.decode()) Respuesta larga : luego, la diferencia entre RequestFactory y Client : se ha desarrollado un poco aquí: Django test RequestFactory vs Client , pero me gustaría completarlo un poco.
En términos de funcionalidad, el Client maneja toda la pila utilizada para procesar la respuesta, incluidos los middlewares y las resoluciones de URL (coincidencia de URL y extracción de parámetros). Por otro lado, RequestFactory , solo crea un objeto de solicitud, dejando la responsabilidad al usuario de agregar los atributos adecuados y llamar a las funciones de vista o métodos de vista apropiados.
De ahí la llamada a ClassView.as_view()(request, *args, **kwargs) en el segundo caso.
En términos de prueba , Client se centra en la prueba de integración (probará que todas las partes encajen juntas: middleware, vista de función/basada en clase, plantilla, etiquetas de plantilla), es el mecanismo de extremo a extremo que está probando aquí .
Cliente -> { UrlResolver -> Middleware -> Ver -> Middlewares -> TemplateResponse } -> Pruebas
Al usar RequestFactory , puede concentrarse en probar partes más pequeñas, un método de vista basado en clases, una vista de funciones, un método de middleware, etc. En ese sentido, RequestFactory está más relacionado con las pruebas unitarias .
Ver Solicitar referencia de fábrica
Si le interesan las pruebas unitarias y los métodos de simulación, no hay mucha literatura al respecto, pero puede consultar este artículo (Prueba de las vistas de Django de forma aislada)[ https://matthewdaly.co.uk/blog/2015/08/02 /testing-django-views-in-isolation/] .
Al final, todo depende de cuánto tiempo pueda dedicar a las pruebas. Las pruebas de integración/funcionales/unitarias tienen diferentes ventajas y desventajas.
Consejos (pueden ser sesgados): Si desarrolla un sitio web, le aconsejo lo siguiente:
Las piezas de prueba unitarias que usan RequestFactory le llevarán más tiempo y no traerán muchos beneficios sobre el uso de la API del Client . Al usar la API del Client , estará más cerca de cómo se usará su sitio web y cómo se comportará.