Tutorial Campo de entrenamiento 2526 - Historial de revisiones

Jmorenol: /* Parte 2: Creamos pruebas para nuestra aplicación UVLHUB */

2025-10-10T08:21:25Z

‎Parte 2: Creamos pruebas para nuestra aplicación UVLHUB

Jmorenol: /* Pruebas de cobertura con pytest-cov */

2025-10-10T08:16:45Z

‎Pruebas de cobertura con pytest-cov

Jmorenol: /* Pruebas de integración con pytest */

2025-10-10T08:15:02Z

‎Pruebas de integración con pytest

Jmorenol: /* Pruebas unitarias con pytest */

2025-10-10T08:13:30Z

‎Pruebas unitarias con pytest

Jmorenol: /* Pruebas de interfaz con Selenium */

2025-10-07T09:49:07Z

‎Pruebas de interfaz con Selenium

Jmorenol: /* Configuración del entorno de pruebas con conftest.py */

2025-10-07T09:46:58Z

‎Configuración del entorno de pruebas con conftest.py

Jmorenol: /* Algunas cuestiones que puedes investigar */

2025-10-07T09:28:46Z

‎Algunas cuestiones que puedes investigar

Jmorenol: /* Ejecución de Locust */

2025-10-07T09:26:56Z

‎Ejecución de Locust

Jmorenol: /* Ejecución de Locust */

2025-10-07T09:25:09Z

‎Ejecución de Locust

Jmorenol: /* Ejecución de Locust */

2025-10-07T09:24:48Z

‎Ejecución de Locust

@@ Línea 625: / Línea 625: @@
 == Parte 2: Creamos pruebas para nuestra aplicación UVLHUB ==
-Con lo que hemos aprendido hasta ahora, ya tenemos las herramientas necesarias para poder diseñar pruebas automatizadas para nuestra aplicación UVLHUB. Por ejemplo, ¿qué tipo de pruebas podrías desarrollar para probar la nueva funcionalidad de notepads que creaste en la primera práctica del curso?
+Con lo que hemos aprendido hasta ahora, tanto en la clase de teoría como en esta práctica sobre automatización, ya tenemos las herramientas necesarias para poder diseñar e implementar pruebas automatizadas para nuestra aplicación UVLHUB. Por ejemplo, ¿qué tipo de pruebas podrías desarrollar para probar la nueva funcionalidad de notepads que creaste en la primera práctica del curso?
 No obstante, antes de lanzarte a ello quizá pueda ser buena idea echar un ojo a las pruebas ya existentes en el repositorio, que te pueden dar pistas, ideas y estrategias para diseñar las tuyas. Y al hacerlo verás que en UVLHUB se usa <code>rosemary</code>, que facilita todavía más las tareas de testing: <code>https://docs.uvlhub.io/rosemary/testing</code>.
@@ Línea 658: / Línea 658: @@
 === Algunas cuestiones que puedes investigar ===
-Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas necesarias para comprobar todas las operaciones CRUD del módulo notepad. Pero si has echado un ojo a otras pruebas de diferentes módulos de UVLHUB quizá te hayas encontrado con algunas cosas que no hemos visto en este campo de entrenamiento y que te pueden resultar muy útiles.
+Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas necesarias para comprobar automáticamente todas las operaciones CRUD del módulo notepad. Pero si has echado un ojo a otras pruebas de diferentes módulos de UVLHUB quizá te hayas encontrado con algunas cosas que no hemos visto en este campo de entrenamiento y que te pueden resultar muy útiles.
 Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1), que son clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. Y es probable que hayas visto pruebas unitarias en las que se utilizan mocks (a través de <code>unittest.mock.patch</code> y <code>MagicMock</code>) para simular el comportamiento del repositorio y así probar el servicio de forma aislada, sin tocar datos reales. Este patrón es muy común en aplicaciones reales, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.
@@ Línea 664: / Línea 664: @@
 También verás que las fixtures de UVLHUB son más sofisticadas: además de crear un test_client, preparan datos persistentes en la base de datos usando <code>SQLAlchemy</code>, e incluso gestionan la sesión de usuario mediante <code>Flask-Login</code>. Esto permite probar funcionalidades que dependen del contexto del usuario autenticado, algo que no aparecía en la app de tareas de la primera parte de esta práctica.
 Básicamente, estas técnicas amplían los fundamentos que ya has aprendido: la estructura y filosofía de las pruebas es la misma, pero ahora se aplican en un entorno más realista y con dependencias que reflejan la complejidad de una aplicación web completa.
 ¡Mucho ánimo!

@@ Línea 363: / Línea 363: @@
 Para asegurarnos de que nuestras pruebas unitarias tienen una buena cobertura de código, vamos a utilizar <code>pytest-cov</code>, una herramienta que extiende <code>pytest</code> para generar un informe sobre qué porcentaje del código ha sido cubierto por las pruebas.
-Y, ¿qué es la cobertura de código?
+<code>pytest-cov</code> mide el porcentaje de código ejecutado cuando se lanzan las pruebas para ayudarte a identificar las áreas de la aplicación que no están siendo probadas adecuadamente. Por tanto, ¿qué criterio de cobertura de los estudiados en clase de teoría usa <code>pytest-cov</code>?
 ===== Medir la cobertura de las pruebas con pytest-cov =====

← Revisión anterior		Revisión del 08:15 10 oct 2025
Línea 347:		Línea 347:

	De nuevo, lee el código de las pruebas e intenta deducir qué hace cada línea. En base a las pruebas manuales que has realizado antes, ¿crees que todas estas pruebas van a funcionar bien?		De nuevo, lee el código de las pruebas e intenta deducir qué hace cada línea. En base a las pruebas manuales que has realizado antes, ¿crees que todas estas pruebas van a funcionar bien?
		+
		+	Y, al igual que hiciste previamente, ¿puedes intuir qué técnicas de diseño de pruebas se han utilizado para su definición?

	==== Ejecución de las pruebas unitarias y de integración ====		==== Ejecución de las pruebas unitarias y de integración ====

← Revisión anterior		Revisión del 08:13 10 oct 2025
Línea 264:		Línea 264:

	Lee el código de las pruebas e intenta deducir qué hace cada línea. En base a las pruebas manuales que has realizado antes, ¿crees que todas estas pruebas van a funcionar bien?		Lee el código de las pruebas e intenta deducir qué hace cada línea. En base a las pruebas manuales que has realizado antes, ¿crees que todas estas pruebas van a funcionar bien?
		+
		+	Y, aunque esta práctica está centrada en la fase de automatización de pruebas, es importante que también reflexiones sobre la fase de diseño de pruebas. Por tanto, vuelve a echar un ojo a las pruebas y trata de identificar qué técnicas de diseño de las que hemos estudiado en la clase de teoría crees que se han seguido para su definición.

	==== Pruebas de integración con <code>pytest</code> ====		==== Pruebas de integración con <code>pytest</code> ====

@@ Línea 495: / Línea 495: @@
 ¿Has visto cómo se ha lanzado el navegador y ha ido realizando los pasos indicados en el archivo <code>tests/test_interface.py</code>?
-En relación al código utilizado, ten en cuenta que se ha usado <code>time.sleep(1)</code> por simplicidad, pero es una práctica poco fiable. Una prueba puede fallar porque la red o el equipo van lentos y la página tarda más de 1 segundo en cargar. Si subes el tiempo (ej. <code>time.sleep(10)</code>), haces las pruebas innecesariamente lentas. La solución es utilizar esperas explícitas (explicit waits), tal como se verás que se hace en UVLHUB, con las que se indica a Selenium que espere hasta que una condición se cumpla (por ejemplo, hasta que un elemento sea visible), con un tiempo máximo de espera.
+En relación al código utilizado, ten en cuenta que se ha usado <code>time.sleep(1)</code> por simplicidad, pero es una práctica poco fiable. Una prueba puede fallar porque la red o el equipo van lentos y la página tarda más de 1 segundo en cargar. Si subes el tiempo (ej. <code>time.sleep(10)</code>), haces las pruebas innecesariamente lentas. La solución es utilizar esperas explícitas, tal como se verás que se hace en UVLHUB, con las que se indica a Selenium que espere hasta que una condición se cumpla (por ejemplo, hasta que un elemento sea visible), con un tiempo máximo de espera.
 ==== <code>Selenium IDE</code> ====

@@ Línea 219: / Línea 219: @@
 </syntaxhighlight>
-Ten en cuenta que se ha usado <code>sys.path.append</code> por simplicidad, pero se considera una práctica un poco anticuada y frágil. Una alternativa más moderna y robusta, como has visto con Rosemary en UVLHUB, es convertir el proyecto en un paquete instalable. Para ello, se crearía un archivo <code>setup.py</code> en la raíz del proyecto y luego se instalaría en modo editable con el comando <code>pip install -e .</code>. De esta forma, pytest encontraría el paquete app automáticamente.
+Ten en cuenta que se ha usado <code>sys.path.append</code> por simplicidad, pero se considera una práctica un poco anticuada y frágil. Una alternativa más moderna y robusta, como has visto con Rosemary en prácticas anteriores, es convertir el proyecto en un paquete instalable. Para ello, se crearía un archivo <code>setup.py</code> en la raíz del proyecto y luego se instalaría en modo editable con el comando <code>pip install -e .</code>. De esta forma, pytest encontraría el paquete app automáticamente.
 ==== Pruebas unitarias con <code>pytest</code> ====

@@ Línea 600: / Línea 600: @@
 Luego, inicia la prueba.
-En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:
+En la terminal verás mensajes como estos hasta que se finalice la prueba:
 <pre>
@@ Línea 615: / Línea 615: @@
 Creando una nueva tarea...
 Tarea creada correctamente.
 </pre>

@@ Línea 594: / Línea 594: @@
 Abre la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) y configura:
-# el número de usuarios (por ejemplo, 10)
+* el número de usuarios (por ejemplo, 10)
-# la tasa de generación, es decir, cada cuánto tiempo se lanza un nuevo usuario (por ejemplo, 1)
+* la tasa de generación, es decir, cada cuánto tiempo se lanza un nuevo usuario (por ejemplo, 1)
-# y el host sobre el que realizar las pruebas (<code>http://localhost:5000</code>).
+* y el host sobre el que realizar las pruebas (<code>http://localhost:5000</code>).
 Luego, inicia la prueba.

@@ Línea 581: / Línea 581: @@
 ===== Ejecución de <code>Locust</code> =====
-# Inicia la aplicación Flask si no estaba en ejecución:
+Inicia la aplicación Flask si no estaba en ejecución:
 <syntaxhighlight lang="bash">
@@ Línea 587: / Línea 587: @@
 </syntaxhighlight>
-# Inicia Locust:
+Inicia Locust:
 <syntaxhighlight lang="bash">
@@ Línea 593: / Línea 593: @@
 </syntaxhighlight>
-# Abre la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) y configura el número de usuarios -por ejemplo, 10-, la tasa de generación (cada cuánto tiempo se lanza un nuevo usuario)-por ejemplo, 1- y el host sobre el que realizar las pruebas (<code>http://localhost:5000</code>). Luego, inicia la prueba.
+Abre la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) y configura:
-# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:
+Luego, inicia la prueba.
 <pre>