Diferencia entre revisiones de «Pruebas unitarias 23-24»
(→Pruebas unitarias 23-24) |
|||
| Línea 6: | Línea 6: | ||
Ten en cuenta que esta prueba sólo sirve para familiarizarnos con el framework. Aquí no estamos probando nuestra app Django. | Ten en cuenta que esta prueba sólo sirve para familiarizarnos con el framework. Aquí no estamos probando nuestra app Django. | ||
| − | < | + | <syntaxhighlight lang="python"> |
from django.test import TestCase | from django.test import TestCase | ||
class SimpleTest(TestCase): | class SimpleTest(TestCase): | ||
| Línea 14: | Línea 14: | ||
""" | """ | ||
self.assertEqual(1 + 1, 2) | self.assertEqual(1 + 1, 2) | ||
| − | </ | + | </syntaxhighlight> |
Para ejecutar este test, deberemos ejecutar: | Para ejecutar este test, deberemos ejecutar: | ||
Revisión actual del 12:50 1 oct 2023
Las pruebas unitarias están destinadas a identificar errores en partes pequeñas de código con la idea de maximizar la cobertura de nuestros tests. El nivel de cobertura de las pruebas, es algo que debemos decidir. Los tests de cada módulo se implementan en archivos python que comienzan por test*.
EJERCICIO 1: CONOCIENDO LAS PRUEBAS UNITARIAS
Lo primero que vamos a hacer es crear un nuevo test para el modulo de autenticación de decide, donde, en lugar de probar la aplicación, comprobaremos que la suma de dos enteros es correcta. Ten en cuenta que esta prueba sólo sirve para familiarizarnos con el framework. Aquí no estamos probando nuestra app Django.
from django.test import TestCase
class SimpleTest(TestCase):
def test_basic_addition(self):
"""
Tests that 1 + 1 always equals 2.
"""
self.assertEqual(1 + 1, 2)
Para ejecutar este test, deberemos ejecutar:
./manage.py test authenticationPara poder diseñar nuevos casos de prueba, debemos conocer primero el estado actual de decide. Para ello, podríamos hacer un análisis de cobertura, que nos permitirá conocer qué partes del código están contempladas en las pruebas que ya tenemos, y qué partes quedan aún por probar.
EJERCICIO 2: ANÁLISIS DE COBERTURA Para lanzar el análisis de cobertura:
coverage run --source . ./manage.py testAñadimos la opción --source . para sólo analizar nuestro código de decide, pero no las bibliotecas incluidas. Añadimos la opción -v 2 para hacer la salida más verbosa y obtener más información sobre la ejecución de los tests. Podemos, también, añadir la opción --keepdb, para evitar que la base de datos de prueba se borre al finalizar. Esto evitará, entre otras cosas, que se tenga que crear la base de datos la próxima vez que vayan a ejecutarse los test.
Para obtener un informe con un aspecto más manejable y navegable, podemos hacer:
coverage htmlQue generará un website bajo el directorio decide/htmlcov/index.html.
EJERCICIO 3: IDENTIFICANDO LOS TESTS QUE FALTAN
En este ejercicio, visualizaremos el report generado por coverage, para identificar las partes del código que no han sido probadas.
