Quiero comenzar a integrar pruebas unitarias en mis proyectos de Django y descubrí que las pruebas unitarias de una vista son complicadas debido a la forma en que Django implementa las vistas con las funciones.¿Cómo pruebo la unidad Django Views?
Por ejemplo, cada función es una vista/página en Django si la función tiene una URL.
¿Cómo puedo probar las vistas de Django?
No estoy seguro de cómo probar una vista es complicado.
Usted acaba de utilizar el test client.
La cobertura del código es fácil. Usted razona cómo una solicitud de URL se correlaciona con una ruta de código y realiza las solicitudes de URL adecuadas.
Puede, si lo desea, llamar a las funciones de vista "manualmente" creando un objeto Request y examinando el objeto Response, pero esto es demasiado trabajo.
Si tiene dudas sobre la cobertura de su código, eso es algo bueno. Significa que tienes un código que no puedes asignar fácilmente a una URL (que es lo único que un usuario puede ver de una aplicación web). Si tienes un código que no se asigna a una URL, probablemente deberías (a) borrar el código o (b) refactorizarlo en un módulo separado.
Tenemos muchos módulos fuera de nuestras funciones de visualización. Nuestras funciones de vista importan estos módulos. Probamos estos módulos "fuera de la función de visualización" con la prueba de unidad ordinaria.
Aquí hay una estructura típica.
some_big_product/
|-- __init__.py
|-- settings.py
|-- urls.py
|-- logging.ini
|-- other_global_files.py
|-- an_app_1/
| |-- __init__.py
| |-- urls.py
| |-- models.py
| |-- views.py
| |-- tests.py <-- the generic Django testing
| |-- app_specific_module.py
| |-- app_specific_package/
| | |-- __init__.py
| |-- test_app_specific_module.py <-- unittest
| |-- test_app_specific_package.py
|-- generic_module.py
|-- generic_package/
| |-- __init__.py
|-- tests/
| |-- test_this.py
| |-- test_that.py
| |-- test_all.py <-- not always practical
|-- scripts/
|-- run_tests.sh
Puedes probar tddspry - colección de ayudantes para probar Django con test nariz y sarga. La nariz también tiene un plugin de cobertura que genera informes bonitos de la cobertura.
Hmm esto podría responder a otra pregunta que tengo. ¿Cómo se gestiona la estructura del directorio cuando se agregan otros módulos en la jerarquía del proyecto/aplicación django? –
¡Gracias! Eso ayuda mucho. –
¿Cómo podría funcionar test_all.py? Supongo que me gustaría poner todo en un gran TestCase.TestSuite, y luego ejecutarlo. De esta forma, todas las estadísticas de prueba (pases y fallos) se agregan en una sola salida al final. No puedo decidir si debería personalizar la "prueba manage.py" de Django para ejecutar las pruebas de unidades adicionales, o escribir mi propio corredor de pruebas de nivel superior que incorpore las pruebas unitarias de Django. –