Pruebas unitarias 23-24 - Historial de revisiones

Brgutierrez en 11:50 1 oct 2023

2023-10-01T11:50:51Z

Brgutierrez: /* Pruebas unitarias 23-24 */

2023-10-01T11:38:15Z

‎Pruebas unitarias 23-24

Brgutierrez: Página creada con «= 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...»

2023-10-01T11:37:26Z

Página creada con «= 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...»

Página nueva

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

<source>
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)
</source>

Para ejecutar este test, deberemos ejecutar:
<source>./manage.py test authentication</source>

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:
<source>coverage run --source . ./manage.py test </source>
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:
<source>coverage html</source>

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.

← Revisión anterior		Revisión del 11:38 1 oct 2023
Línea 1:		Línea 1:
−	~~= 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*.		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*.

@@ 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.
-<source>
+‎<syntaxhighlight lang="python">
 from django.test import TestCase
 class SimpleTest(TestCase):
@@ Línea 14: / Línea 14: @@
   """
   self.assertEqual(1 + 1, 2)
-</source>
+‎</syntaxhighlight>
 Para ejecutar este test, deberemos ejecutar: