Pruebas unitarias 23-24

Pruebas unitarias 23-24

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 authentication

Para 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 test

Añ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 html

Que 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.