Wiki de EGC - Contribuciones del usuario [es]

Archivo:EGC 2025-26 Plantilla Seguimiento 2.pptx

2025-12-01T19:27:01Z

Jmorenol: Jmorenol subió una nueva versión de Archivo:EGC 2025-26 Plantilla Seguimiento 2.pptx

Prácticas - 25/26

2025-12-01T19:21:57Z

Jmorenol:

[[Página_Principal]] -> [[2025/2026]] -> [[Prácticas - 25/26]]

== Prácticas ==

* Práctica 1: '''Instalación del sistema base''' [[Archivo:EGC 2025-26 P1.pdf]]
* Práctica 2: '''Integración y despliegue continuos ''' [[Archivo:EGC 2025-26 P2.pdf]]
** [[Workflows solución P2 2526 |Workflows solución para los ejercicios propuestos]]
* Práctica 3: '''Gestión del código fuente''' [[Archivo:EGC_2025-26_P3.pdf]]
** Solución ejercicios alumno/a A: [[Archivo:P3 usuario A 2526.pdf]]
** Solución ejercicios alumno/a B: [[Archivo:P3 usuario B 2526.pdf]]
* Práctica 4: '''Automatización de pruebas''' [[Archivo:EGC_2025-26_P4.pdf]]
* Práctica 5: '''Contenedores, dev-containers y aislamiento''' [[Archivo:EGC_2025-26_P5.pdf]]
*Práctica 6: '''Máquinas virtuales y aprovisionamiento''' [[Archivo:EGC 2025-26 P6.pdf ]]
** Campo de entrenamiento de Vagrant: [[Tutorial Campo de entrenamiento de Vagrant]]
** Tutorial configurando una máquina virtual para una aplicación: [[Tutorial configurando vagrant para una aplicación 2526|Tutorial configurando vagrant para una aplicación]]
** ¡Ahora es el momento de probar con uvlhub! [https://docs.uvlhub.io/installation/installation_with_vagrant]
* Seguimiento 1: [[Archivo:EGC 2025-26 Plantilla Seguimiento 1.pptx]]
* Seguimiento 2: [[Archivo:EGC 2025-26 Plantilla Seguimiento 2.pptx]]

----

==== Material adicional para el desarrollo de las sesiones prácticas ====

* Box con la imagen de Ubuntu de los equipos de laboratorio de prácticas : [https://portal.cloud.hashicorp.com/vagrant/discover/cdcetsii/UbuntuEGC_25]

Archivo:EGC 2025-26 Plantilla Seguimiento 2.pptx

2025-12-01T19:20:57Z

Jmorenol:

Prácticas - 25/26

2025-11-25T07:20:06Z

Jmorenol: /* Prácticas */

[[Página_Principal]] -> [[2025/2026]] -> [[Prácticas - 25/26]]

== Prácticas ==

* Práctica 1: '''Instalación del sistema base''' [[Archivo:EGC 2025-26 P1.pdf]]
* Práctica 2: '''Integración y despliegue continuos ''' [[Archivo:EGC 2025-26 P2.pdf]]
** [[Workflows solución P2 2526 |Workflows solución para los ejercicios propuestos]]
* Práctica 3: '''Gestión del código fuente''' [[Archivo:EGC_2025-26_P3.pdf]]
** Solución ejercicios alumno/a A: [[Archivo:P3 usuario A 2526.pdf]]
** Solución ejercicios alumno/a B: [[Archivo:P3 usuario B 2526.pdf]]
* Práctica 4: '''Automatización de pruebas''' [[Archivo:EGC_2025-26_P4.pdf]]
* Práctica 5: '''Contenedores, dev-containers y aislamiento''' [[Archivo:EGC_2025-26_P5.pdf]]
*Práctica 6: '''Máquinas virtuales y aprovisionamiento''' [[Archivo:EGC 2025-26 P6.pdf ]]
** Campo de entrenamiento de Vagrant: [[Tutorial Campo de entrenamiento de Vagrant]]
** Tutorial configurando una máquina virtual para una aplicación: [[Tutorial configurando vagrant para una aplicación 2526|Tutorial configurando vagrant para una aplicación]]
** ¡Ahora es el momento de probar con uvlhub! [https://docs.uvlhub.io/installation/installation_with_vagrant]
* Seguimiento 1: [[Archivo:EGC 2025-26 Plantilla Seguimiento 1.pptx]]

----

==== Material adicional para el desarrollo de las sesiones prácticas ====

* Box con la imagen de Ubuntu de los equipos de laboratorio de prácticas : [https://portal.cloud.hashicorp.com/vagrant/discover/cdcetsii/UbuntuEGC_25]

Prácticas - 25/26

2025-11-25T07:19:46Z

Jmorenol: /* Prácticas */

[[Página_Principal]] -> [[2025/2026]] -> [[Prácticas - 25/26]]

== Prácticas ==

* Práctica 1: '''Instalación del sistema base''' [[Archivo:EGC 2025-26 P1.pdf]]
* Práctica 2: '''Integración y despliegue continuos ''' [[Archivo:EGC 2025-26 P2.pdf]]
** [[Workflows solución P2 2526 |Workflows solución para los ejercicios propuestos]]
* Práctica 3: '''Gestión del código fuente''' [[Archivo:EGC_2025-26_P3.pdf]]
** Solución ejercicios alumno/a A: [[Archivo:P3 usuario A 2526.pdf]]
** Solución ejercicios alumno/a B: [[Archivo:P3 usuario B 2526.pdf]]
* Práctica 4: '''Automatización de pruebas''' [[Archivo:EGC_2025-26_P4.pdf]]
* Práctica 5: '''Contenedores, dev-containers y aislamiento''' [[Archivo:EGC_2025-26_P5.pdf]]
*Práctica 6: '''Máquinas virtuales y aprovisionamiento''' [[Archivo:EGC 2025-26 P6.pdf ]]
** Campo de entrenamiento de Vagrant: [[Tutorial Campo de entrenamiento de Vagrant]]
** Tutorial configurando una máquina virtual para una aplicación: [[Tutorial configurando vagrant para una aplicación 2526|Tutorial configurando vagrant para una aplicación]]
** ¡Ahora es el momento de probar con uvlhub! [https://docs.uvlhub.io/installation/installation_with_vagrant]
* Seguimiento 1: [[EGC 2025-26 Plantilla Seguimiento 1.pptx]]

----

==== Material adicional para el desarrollo de las sesiones prácticas ====

* Box con la imagen de Ubuntu de los equipos de laboratorio de prácticas : [https://portal.cloud.hashicorp.com/vagrant/discover/cdcetsii/UbuntuEGC_25]

Archivo:EGC 2025-26 Plantilla Seguimiento 1.pptx

2025-11-25T07:19:00Z

Jmorenol:

Prácticas - 25/26

2025-11-25T07:13:52Z

Jmorenol: /* Prácticas */

[[Página_Principal]] -> [[2025/2026]] -> [[Prácticas - 25/26]]

== Prácticas ==

* Práctica 1: '''Instalación del sistema base''' [[Archivo:EGC 2025-26 P1.pdf]]
* Práctica 2: '''Integración y despliegue continuos ''' [[Archivo:EGC 2025-26 P2.pdf]]
** [[Workflows solución P2 2526 |Workflows solución para los ejercicios propuestos]]
* Práctica 3: '''Gestión del código fuente''' [[Archivo:EGC_2025-26_P3.pdf]]
** Solución ejercicios alumno/a A: [[Archivo:P3 usuario A 2526.pdf]]
** Solución ejercicios alumno/a B: [[Archivo:P3 usuario B 2526.pdf]]
* Práctica 4: '''Automatización de pruebas''' [[Archivo:EGC_2025-26_P4.pdf]]
* Práctica 5: '''Contenedores, dev-containers y aislamiento''' [[Archivo:EGC_2025-26_P5.pdf]]
*Práctica 6: '''Máquinas virtuales y aprovisionamiento''' [[Archivo:EGC 2025-26 P6.pdf ]]
** Campo de entrenamiento de Vagrant: [[Tutorial Campo de entrenamiento de Vagrant]]
** Tutorial configurando una máquina virtual para una aplicación: [[Tutorial configurando vagrant para una aplicación 2526|Tutorial configurando vagrant para una aplicación]]
** ¡Ahora es el momento de probar con uvlhub! [https://docs.uvlhub.io/installation/installation_with_vagrant]
* Seguimiento 1: [https://hdvirtual.us.es/discovirt/index.php/s/4TB88sdzSHBzK7q Gestión del código fuente e incidencias]

----

==== Material adicional para el desarrollo de las sesiones prácticas ====

* Box con la imagen de Ubuntu de los equipos de laboratorio de prácticas : [https://portal.cloud.hashicorp.com/vagrant/discover/cdcetsii/UbuntuEGC_25]

Tutorial configurando vagrant para una aplicación 2526

2025-11-18T08:47:01Z

Jmorenol: /* Estructura del Proyecto */

= Despliegue de una Aplicación Python en Vagrant =

== Introducción ==
Este tutorial te guiará en el despliegue de una aplicación Flask utilizando Vagrant, Ansible y Shell scripts. La finalidad es entender cómo automatizar la configuración y despliegue de aplicaciones en entornos virtuales reproducibles, como los que proporciona Vagrant.

== ¿Por qué utilizamos Vagrant? ==
Vagrant es una herramienta de administración de entornos virtuales que permite definir en un archivo (llamado `Vagrantfile`) las especificaciones necesarias para crear, configurar y aprovisionar una máquina virtual de manera rápida y consistente. Vagrant es especialmente útil en desarrollo y pruebas, ya que nos permite configurar un entorno de desarrollo idéntico al entorno de producción en cuestión de minutos y garantiza que cada miembro del equipo de desarrollo trabaje en un entorno coherente.

Con Vagrant, evitamos el clásico problema de "en mi máquina funciona" al tener un entorno idéntico en cada ejecución, independientemente de la máquina en la que se esté corriendo el proyecto. En este tutorial, usaremos Vagrant para crear una máquina virtual de Linux donde desplegaremos nuestra aplicación de Flask.

== ¿Qué es el Aprovisionamiento? ==
Aprovisionar, en el contexto de máquinas virtuales y Vagrant, se refiere al proceso de instalar y configurar el software necesario en una máquina virtual para que pueda ejecutar una aplicación. Cuando aprovisionamos una máquina, estamos automatizando la instalación de dependencias, configuraciones de sistema, servicios necesarios (como bases de datos), y otras tareas de configuración que preparan el entorno para ejecutar la aplicación.

=== Métodos de Aprovisionamiento ===
En este tutorial veremos dos métodos de aprovisionamiento:

1. '''Mediante un script de shell''': Usando un archivo `.sh` (como `provision.sh`), que contiene comandos de terminal para instalar y configurar los componentes necesarios.

2. '''Mediante Ansible''': Usando un archivo de configuración llamado `playbook.yml`, que describe de manera declarativa lo que queremos instalar y configurar en la máquina virtual.

=== ¿Por qué utilizar Ansible para el Aprovisionamiento? ===
Ansible es una herramienta de automatización de TI que permite gestionar la configuración, el despliegue y la orquestación de sistemas. Comparado con los scripts de shell, Ansible ofrece varias ventajas:
* '''Declarativo y legible''': Un playbook de Ansible describe el estado deseado del sistema (qué queremos conseguir), en lugar de los pasos para llegar a ese estado (cómo hacerlo), lo cual hace que sea más legible y fácil de mantener.
* '''Idempotencia''': Ansible ejecuta las tareas de manera idempotente, lo que significa que si ejecutamos el playbook varias veces, el sistema solo aplicará los cambios necesarios, evitando que se realicen operaciones innecesarias.
* '''Escalabilidad y organización''': Ansible permite crear playbooks para gestionar múltiples servidores de manera centralizada, lo cual es esencial en ambientes de producción donde hay decenas o cientos de servidores.
* '''Ecosistema y comunidad''': Ansible es una herramienta popular con una gran comunidad de usuarios y módulos preexistentes para una amplia variedad de tareas, lo que facilita extender la funcionalidad y resolver problemas comunes rápidamente.

=== ¿Cuándo es mejor utilizar un script de shell y cuándo Ansible? ===
Para proyectos pequeños o configuraciones rápidas, un script de shell puede ser suficiente. Sin embargo, para entornos más complejos, donde la repetición, escalabilidad y legibilidad son factores importantes, Ansible es preferible debido a su idempotencia, claridad y modularidad.

En este tutorial, vamos a provisionar un entorno para nuestra aplicación Flask de ambas maneras, para que puedas comparar los métodos y comprender en qué casos uno puede ser más ventajoso que el otro.

== Nuestra Aplicación: Gestión de Tareas ==
La aplicación que desplegaremos es una sencilla aplicación de gestión de tareas, utilizada previamente en otras prácticas. Esta aplicación está basada en Flask, un framework de desarrollo web en Python, y ahora utilizará una base de datos MariaDB para almacenar información. El propósito de este tutorial es aprender a desplegar la aplicación en un entorno controlado y reproducible usando Vagrant y los métodos de aprovisionamiento mencionados anteriormente.

== Estructura del Proyecto ==
Para esta práctica, el proyecto debería presentar la siguiente estructura de archivos:
<pre>
flask_testing_project/
├── .env
├── config.py
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
└── └── tasks.html
</pre>

Y el siguiente contenido:

===== Código <code>.env</code>: =====

El archivo .env es un estándar para almacenar configuraciones que varían entre entornos (desarrollo, pruebas, producción) y que no deben ser hardcodeadas o subidas a repositorios de código (como contraseñas). El paquete python-dotenv cargará estas variables en el entorno de la aplicación al inicio.

'''Finalidad:''' Centralizar todas las credenciales de MariaDB y los secretos de Flask, facilitando que tanto el script de aprovisionamiento de Vagrant como la aplicación Flask accedan a ellas.

<syntaxhighlight lang="bash">

# .env file (Usado en Local y en Vagrant)

# --- 1. Credenciales de la Base de Datos (Para la aplicación Flask) ---
DATABASE_USER=flask_user
DATABASE_PASSWORD=flask_password
DATABASE_HOST=localhost
DATABASE_DB=tasks_db

# --- 2. Variables de la Aplicación Flask ---
SECRET_KEY=una-clave-secreta-larga-y-unica

# --- 3. Credenciales de MariaDB Root ---
MYSQL_ROOT_PASSWORD=su_contraseña_root_segura

</syntaxhighlight>

===== Código <code>config.py</code>: =====

Este módulo define clases de configuración que heredan de una base (Config) y permiten aplicar ajustes específicos para diferentes entornos (ej. DEBUG = True solo en DevelopmentConfig).

'''Finalidad:''' Construir la cadena de conexión de la base de datos (SQLALCHEMY_DATABASE_URI) a partir de las variables individuales leídas del entorno (os.environ.get(...)), asegurando que la aplicación sepa cómo conectarse a MariaDB.

<syntaxhighlight lang="python">

import os

# Configuración base (compartida entre entornos)
class Config:
# Lee SECRET_KEY del .env
SECRET_KEY = os.environ.get('SECRET_KEY') or 'fallback-clave-secreta'

# Lee las variables individuales de la DB
DB_USER = os.environ.get('DATABASE_USER')
DB_PASS = os.environ.get('DATABASE_PASSWORD')
DB_HOST = os.environ.get('DATABASE_HOST')
DB_NAME = os.environ.get('DATABASE_DB')

# Construye la URL de conexión
SQLALCHEMY_DATABASE_URI = (
f'mysql+pymysql://{DB_USER}:{DB_PASS}@{DB_HOST}/{DB_NAME}'
if DB_USER and DB_PASS and DB_HOST and DB_NAME else None
)

SQLALCHEMY_TRACK_MODIFICATIONS = False

# Configuración específica para desarrollo
class DevelopmentConfig(Config):
DEBUG = True

</syntaxhighlight>

===== Código <code>__init__.py</code>: =====

Este archivo es el módulo de inicialización del paquete Python app. Contiene una única línea de código que expone la función principal del paquete.

'''Finalidad:''' Actúa como un proxy o puente para que cualquier otro archivo que necesite acceder a la función fábrica de la aplicación (como el comando flask o scripts externos) pueda importarla directamente usando from app import create_app, sin tener que especificar el archivo interno app.app. Simplemente hace que la función create_app definida en app.py sea accesible al nivel superior del paquete app.

<syntaxhighlight lang="python">

from .app import create_app

</syntaxhighlight>

===== Código <code>app.py</code>: =====

Este módulo contiene la función fábrica de la aplicación (create_app), el corazón de la arquitectura Flask. Es responsable de crear y configurar la instancia de la aplicación de manera flexible, permitiendo diferentes configuraciones (como Desarrollo o Pruebas).

'''Finalidad:''' La función create_app es el punto de control central que:

1) Carga el Entorno: Usa load_dotenv() para cargar variables de configuración (credenciales de DB, SECRET_KEY) desde el archivo .env.

2) Configura la Aplicación: Aplica los ajustes específicos de entorno (tomados de config.py) a la instancia de Flask.

3) Inicializa Extensiones: Vincula extensiones como SQLAlchemy (db.init_app) y Flask-Migrate a la aplicación.

4) Registra Rutas: Agrega los módulos de rutas (los Blueprints) a la aplicación, completando la configuración antes de ser devuelta.

<syntaxhighlight lang="python">

from flask import Flask
from app.routes import bp as tasks_blueprint
from .models import db # SQLAlchemy instance
from flask_migrate import Migrate
from config import DevelopmentConfig # Importamos la configuración
from dotenv import load_dotenv
import os

load_dotenv()

def create_app(config_class=DevelopmentConfig): # Usa Desarrollo por defecto
app = Flask(__name__)

# 1. Aplicar la configuración
app.config.from_object(config_class)

# 2. Inicializar extensiones
db.init_app(app)
# Inicializar Flask-Migrate (necesita app y db)
Migrate(app, db)

app.register_blueprint(tasks_blueprint)

return app

</syntaxhighlight>

===== Código <code>models.py</code>: =====

Este módulo define el Modelo Relacional de Objetos utilizando Flask-SQLAlchemy (ORM).

'''Finalidad:''' Declarar la estructura de la tabla tasks y proporcionar funciones de acceso a datos de alto nivel (get_all_tasks, create_task) que interactúan con la base de datos de manera segura dentro de un contexto de aplicación (current_app.app_context()).

<syntaxhighlight lang="python">

from flask_sqlalchemy import SQLAlchemy
from flask import current_app

db = SQLAlchemy()

class Task(db.Model):
__tablename__ = 'tasks'
id = db.Column(db.Integer, primary_key=True)
title = db.Column(db.String(100), nullable=False)
done = db.Column(db.Boolean, default=False)

def to_dict(self):
return {
'id': self.id,
'title': self.title,
'done': self.done
}

# --- Funciones de Acceso a Datos ---

def get_all_tasks():
with current_app.app_context():
return [task.to_dict() for task in Task.query.order_by(Task.id).all()]

def create_task(title):
if not title:
raise ValueError("El título es necesario")

with current_app.app_context():
new_task = Task(title=title, done=False)
db.session.add(new_task)
db.session.commit()
return new_task.to_dict()

</syntaxhighlight>

===== Código <code>routes.py</code>: =====

Este módulo utiliza el concepto de Blueprint de Flask para organizar las rutas y vistas de la aplicación, separando la lógica de enrutamiento de la lógica de la fábrica.

'''Finalidad:''' Define los endpoints HTTP (/, /add_task, /tasks). Incluye rutas para la interfaz web (render_template) y endpoints API (jsonify) que llaman a las funciones de acceso a datos definidas en models.py.

<syntaxhighlight lang="python">

from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

===== Archivo <code>templates/tasks.html</code>: =====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

<syntaxhighlight lang="html">

<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

===== Script <code>local_setup.sh</code> para lanzar la app en local =====

Si quieres lanzar la aplicación de manera local, puedes utilizar este script:

<syntaxhighlight lang="bash">

#!/bin/bash

# =========================================================================
# SCRIPT DE SETUP Y LANZAMIENTO LOCAL PARA FLASK CON MARIADB
# =========================================================================

# --- 0. Asegurar la ubicación ---
# Cambia al directorio del script. Esto garantiza que encuentre .env y .venv.
cd "$(dirname "$0")"
echo "Directorio de trabajo actual: $(pwd)"

# --- 1. Variables y Rutas del Entorno Virtual ---
# Definimos las rutas a los binarios DENTRO del venv para usar rutas ABSOLUTAS.
VENV_DIR=".venv"
PYTHON_BIN="$VENV_DIR/bin/python"
PIP_BIN="$VENV_DIR/bin/pip"
FLASK_BIN="$VENV_DIR/bin/flask"

# --- 2. Cargar Variables de Configuración desde .env ---
echo "--- 1. Cargando configuración desde el archivo .env ---"

if [ ! -f .env ]; then
echo "❌ ERROR: El archivo .env no se encontró en $(pwd). ¡Crealo primero!"
exit 1
fi

. .env

# Comprobación de carga
if [ -z "$DATABASE_DB" ]; then
echo "❌ ERROR: Las variables de la base de datos (ej. DATABASE_DB) no se cargaron correctamente."
exit 1
fi
echo "✅ Variables cargadas: Usuario=$DATABASE_USER, DB=$DATABASE_DB"

# --- 3. Preparar Entorno Python e Instalar Dependencias ---
echo "--- 2. Creando Entorno Virtual Python (.venv) ---"

# Crear el entorno virtual si no existe
if [ ! -d "$VENV_DIR" ]; then
python3 -m venv "$VENV_DIR"
fi

# Usando el PIP ABSOLUTO del entorno virtual para la instalación
echo "--- Instalando dependencias necesarias (Flask, SQLAlchemy, PyMySQL, etc.) ---"
"$PIP_BIN" install --upgrade pip
# Lista de dependencias clave para el proyecto:
"$PIP_BIN" install flask python-dotenv flask-sqlalchemy pymysql flask-migrate

# --- 4. Generar requirements.txt ---
echo "--- 3. Generando requirements.txt a partir del entorno actual ---"
"$PIP_BIN" freeze > requirements.txt
echo "✅ requirements.txt creado con las dependencias instaladas."

# --- 5. Configuración de MariaDB (Usuario y Base de Datos) ---
echo "--- 4. Configurando usuario y base de datos en MariaDB... ---"

# Se ejecuta el comando SQL con las variables cargadas
# Esto requiere permisos de sudo para acceder al usuario 'root' de MariaDB
sudo mysql -u root <<EOF
CREATE DATABASE IF NOT EXISTS $DATABASE_DB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER IF NOT EXISTS '$DATABASE_USER'@'localhost' IDENTIFIED BY '$DATABASE_PASSWORD';
GRANT ALL PRIVILEGES ON $DATABASE_DB.* TO '$DATABASE_USER'@'localhost';
FLUSH PRIVILEGES;
EOF

echo "✅ Usuario '$DATABASE_USER' y base de datos '$DATABASE_DB' configurados."

# --- 6. Inicializar y Aplicar Migraciones ---
echo "--- 5. Aplicando migraciones de base de datos (Flask-Migrate)... ---"

# Exporta la variable FLASK_APP
export FLASK_APP=app.app:create_app

# Usando el binario de Flask del VENV para ejecutar la migración
"$FLASK_BIN" db upgrade

echo "✅ Migraciones completadas. Las tablas están listas."

# --- 7. Lanzar la Aplicación ---
echo "--- 6. Lanzando el servidor Flask en http://127.0.0.1:5000 ---"

# Usando el binario de Flask del VENV para ejecutar la aplicación
"$FLASK_BIN" run

</syntaxhighlight>

Para lanzarlo, usa:

<syntaxhighlight lang="bash">

chmod +x local_setup.sh
./local_setup.sh

</syntaxhighlight>

= Parte 1: Aprovisionamiento mediante un Script de Shell =
En la primera parte del tutorial, aprovisionaremos el entorno de desarrollo con un script de shell (`provision.sh`).

=== ¿Qué es un archivo con extensión .sh? ===

Un archivo con extensión .sh es un '''script de shell''', un archivo de texto que contiene una serie de comandos escritos en un lenguaje de scripting específico para el shell, el intérprete de comandos que interactúa con el sistema operativo. Los scripts .sh se usan ampliamente en sistemas Unix y Linux, aunque también funcionan en otros entornos compatibles con shells como bash, sh o zsh.

==== ¿Para qué sirven los archivos .sh? ====

Los archivos .sh permiten automatizar tareas, ya que el shell ejecuta cada comando en el archivo de forma secuencial, sin necesidad de intervención manual. Esto es especialmente útil para configurar sistemas, instalar paquetes, mover o copiar archivos, configurar redes, iniciar aplicaciones y realizar prácticamente cualquier acción que se pueda ejecutar desde la línea de comandos.

Por ejemplo, en el contexto de nuestro proyecto con Vagrant y Flask, usaremos un archivo .sh llamado provision.sh para:

Instalar dependencias como Python y Flask.
Configurar la base de datos.
Preparar el entorno de la aplicación.
Esto permite que, al ejecutar vagrant up, el script se ejecute automáticamente, configurando la máquina virtual sin necesidad de realizar los pasos de configuración uno a uno.

==== Cómo se ejecuta un archivo .sh ====

Para ejecutar un archivo .sh en un sistema Linux o Mac, simplemente hay que abrir una terminal y escribir: <syntaxhighlight lang="bash"> sh nombre_del_archivo.sh </syntaxhighlight>

O bien, puedes ejecutar el script con permisos adicionales o en otro shell específico, como bash: <syntaxhighlight lang="bash"> bash nombre_del_archivo.sh </syntaxhighlight>

Cuando Vagrant encuentra un archivo .sh especificado en el Vagrantfile (como en config.vm.provision "shell", path: "provision.sh"), ejecuta ese archivo automáticamente en la máquina virtual como parte del proceso de aprovisionamiento. Esto garantiza que la máquina esté configurada correctamente cada vez que se inicia.

== Crear el Vagrantfile ==

Recuerda que el Vagrantfile es el archivo de configuración que Vagrant utiliza para definir y gestionar una máquina virtual. Este archivo es el núcleo de cualquier proyecto que utilice Vagrant, ya que contiene instrucciones específicas para la configuración de la máquina virtual, incluyendo el sistema operativo, red, sincronización de carpetas, y scripts de aprovisionamiento.

Al colocar el Vagrantfile en el directorio raíz del proyecto (flask_testing_project/), mantenemos todos los recursos y configuraciones necesarias para el despliegue de la aplicación en un solo lugar. Esto hace que el proyecto sea fácil de portar y reproducir, ya que cualquier persona con este directorio y Vagrant puede ejecutar el proyecto en una máquina virtual idéntica.

A continuación, crea un archivo llamado Vagrantfile en el directorio flask_testing_project/ y añade el siguiente contenido:

<syntaxhighlight lang="ruby">
# Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

# 1. Sistema Operativo
config.vm.box = "ubuntu/jammy64"

# 2. Mapear puerto de Flask (5000)
config.vm.network "forwarded_port", guest: 5000, host: 5000

# 3. Provisionamiento: Ejecuta el script completo
config.vm.provision "shell", path: "provision.sh"
end

</syntaxhighlight>

=== Explicación línea a línea del Vagrantfile ===

El archivo Vagrantfile define las especificaciones para crear y configurar la máquina virtual (VM) en la que se ejecutará tu aplicación Flask.

<code>Vagrant.configure("2") do |config|</code>

Esta línea inicia el bloque de configuración del entorno de Vagrant. Indica que estamos utilizando la versión 2 del formato de configuración y asigna un objeto llamado config que se usará para definir todos los ajustes de la máquina virtual.

<code>config.vm.box = "ubuntu/jammy64"</code>

Esta es la línea que define el Sistema Operativo de la máquina virtual. "ubuntu/jammy64" es el nombre de la "caja base" (la imagen del sistema operativo) que Vagrant descargará e instalará. En este caso, se especifica una versión de Ubuntu 64 bits (Jammy Jellyfish, o 22.04 LTS).

<code>config.vm.network "forwarded_port", guest: 5000, host: 5000</code>

Esta línea se encarga del Mapeo de Puertos. Le indica a Vagrant que debe redirigir el tráfico. Específicamente, el puerto 5000 de la máquina anfitriona (tu máquina local, el host) se reenvía al puerto 5000 dentro de la máquina virtual (guest). Esto es crucial porque permite que accedas a la aplicación Flask (que se ejecuta dentro de la VM en el puerto 5000) desde tu navegador web local visitando http://localhost:5000.

<code>config.vm.provision "shell", path: "provision.sh"</code>

Esta línea define el aprovisionamiento. Le indica a Vagrant que, después de arrancar e instalar el sistema operativo, debe ejecutar un script de automatización. El tipo de provisioner es "shell", y el argumento path: "provision.sh" especifica que el archivo a ejecutar es provision.sh, el cual debe encontrarse en el mismo directorio que este Vagrantfile. Este script se encargará de instalar MariaDB, Python y configurar la base de datos y la aplicación.

<code>end</code>

Esta línea simplemente cierra el bloque de configuración iniciado por Vagrant.configure("2").

== Crear el script de aprovisionamiento ==

Este script, llamado provision.sh, es ejecutado por Vagrant cuando se levanta la máquina virtual (vagrant up). Su objetivo es automatizar la instalación de software, la configuración de la base de datos y el despliegue inicial de la aplicación Flask.

En la raíz del proyecto, al mismo nivel que el Vagrantfile, crea un script provision.sh con este contenido:

<syntaxhighlight lang="bash">

#!/bin/bash

# --- 1. Cargar Variables del .env ---
# Carga las credenciales de la DB y la aplicación desde el archivo unificado .env
echo "--- 1. Cargando configuración desde el archivo .env ---"
set -a
# Usamos el path /vagrant para acceder a los archivos del directorio compartido
source /vagrant/.env
set +a

PROJECT_DIR="/vagrant"

# --- 2. Instalación de Dependencias del Sistema ---
echo "--- 2. Instalando MariaDB, Python (>=3.10) y utilidades ---"
sudo apt-get update
# python3-dev es necesario para compilar algunas dependencias
sudo apt-get install -y mariadb-server python3-pip python3-venv git python3-dev

# --- 3. Configuración de MariaDB (Idempotente) ---
echo "--- 3. Configurando MariaDB y creando usuario '$DATABASE_USER' ---"
sudo systemctl enable mariadb
sudo systemctl start mariadb
sleep 5

# Los comandos SQL deben usar la sintaxis más compatible para asegurar la creación del usuario.
sudo mysql -u root <<EOF
-- 3a. Crear la base de datos
CREATE DATABASE IF NOT EXISTS $DATABASE_DB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 3b. Crear/Modificar el usuario con la contraseña
-- Usamos la sintaxis estándar para compatibilidad.
CREATE USER IF NOT EXISTS '$DATABASE_USER'@'localhost' IDENTIFIED BY '$DATABASE_PASSWORD';

-- 3c. Asegurar que el plugin de autenticación sea compatible con PyMySQL (si la versión de MariaDB lo requiere)
-- Nota: Si usas una versión reciente de MariaDB, este paso es implícito o usa IDENTIFIED BY.
-- Lo mantenemos simple para evitar el ERROR 1064.

-- 3d. Otorgar permisos sobre la base de datos
GRANT ALL PRIVILEGES ON $DATABASE_DB.* TO '$DATABASE_USER'@'localhost';

-- 3e. Aplicar los cambios
FLUSH PRIVILEGES;
EOF

echo "✅ MariaDB configurado."

# --- 4. Preparación del Entorno Python ---
echo "--- 4. Configurando entorno Python e instalando requirements.txt ---"
cd $PROJECT_DIR

# 4a. Crear y activar el entorno virtual
if [ ! -d ".venv" ]; then
python3 -m venv .venv
fi
source .venv/bin/activate

# 4b. Instalar dependencias
pip install -r requirements.txt

# --- 5. Migraciones y Creación de Tablas ---
echo "--- 5. Ejecutando migraciones de Flask (Alembic) ---"
export FLASK_APP=app.app:create_app

# 5a. Inicializar el repositorio de migraciones (si no existe)
if [ ! -d "migrations" ]; then
flask db init
fi

# 5b. Crear la migración inicial si es necesario (ESTA ES LA LÍNEA FALTANTE)
# Flask-Migrate solo crea tablas si existe un archivo de versión.
flask db migrate -m "Initial database migration"

# 5c. Aplicar las migraciones. Esto crea las tablas en la base de datos.
flask db upgrade

echo "✅ Base de datos inicializada."

# --- 6. Lanzamiento de la Aplicación ---
echo "--- 6. Iniciando la aplicación Flask en segundo plano (Puerto 5000) ---"

# Detener cualquier instancia previa para idempotencia
pkill -f 'flask run --host=0.0.0.0'

# Iniciar la aplicación en segundo plano con nohup
# El .env se carga automáticamente por python-dotenv
nohup flask run --host=0.0.0.0 > /tmp/flask_app.log 2>&1 &

echo "✅ Aprovisionamiento y lanzamiento completados. Accede en http://localhost:5000"
deactivate

</syntaxhighlight>

=== Explicación paso a paso del script de aprovisionamiento ===

Aquí tienes la explicación detallada del script en texto, agrupada por pasos lógicos:

==== Paso 1: Carga de Variables de Configuración ====

Este bloque asegura que las credenciales de la base de datos y otras variables de entorno definidas en el archivo .env de tu máquina local estén disponibles dentro de la máquina virtual (VM).

<code>set -a</code>: Este comando asegura que todas las variables definidas o modificadas a partir de este punto sean automáticamente exportadas al entorno (export all), haciéndolas accesibles para los comandos subsiguientes como mysql.

<code>source /vagrant/.env</code>: Comando clave. El directorio /vagrant es el punto de montaje predeterminado que conecta el directorio de tu proyecto local con la VM. Este comando lee el archivo .env compartido e inserta sus variables ($DATABASE_USER, $DATABASE_DB, etc.) en el shell de la VM.

<code>set +a</code> Desactiva la exportación automática de variables.

<code>PROJECT_DIR="/vagrant"</code>: Define una variable para el directorio raíz del proyecto, facilitando la navegación posterior.

==== Paso 2: Instalación de Dependencias del Sistema ====

Esta sección se encarga de instalar todo el software que necesita la aplicación para funcionar, asumiendo que la VM comienza con un sistema operativo limpio.

<code>sudo apt-get update</code>: Actualiza la lista de paquetes disponibles en el sistema operativo.

<code>sudo apt-get install -y mariadb-server python3-pip python3-venv git python3-dev</code>: Instala los paquetes esenciales sin pedir confirmación (-y):

* <code> mariadb-server</code>: El servidor de base de datos.

* <code> python3-pip y python3-venv</code>: Herramientas necesarias para gestionar paquetes y crear entornos virtuales de Python.

* <code> git</code>: Útil para gestión de código.

* <code> python3-dev</code>: Necesario para compilar bibliotecas de Python que tienen componentes nativos, como el conector de MariaDB (pymysql).

==== Paso 3: Configuración de MariaDB ====

Este bloque configura la base de datos y el usuario de manera idempotente (es decir, puede ejecutarse varias veces sin causar errores).

<code> sudo systemctl enable mariadb / sudo systemctl start mariadb</code>: Asegura que el servicio MariaDB esté habilitado para arrancar con el sistema y lo inicia inmediatamente.

<code> sleep 5</code>: Espera 5 segundos para que el servicio de la base de datos se inicie completamente antes de intentar ejecutar comandos SQL.

<code> sudo mysql -u root <<EOF ... EOF</code>: Ejecuta los comandos SQL dentro del bloque.

* <code>CREATE DATABASE IF NOT EXISTS $DATABASE_DB ...</code>: Crea la base de datos utilizando la variable cargada, si esta aún no existe.

* <code>CREATE USER IF NOT EXISTS '$DATABASE_USER'@'localhost' ...</code>: Crea el usuario de la aplicación, también utilizando las variables cargadas.

* <code>GRANT ALL PRIVILEGES ON $DATABASE_DB.* TO '$DATABASE_USER'@'localhost'</code>: Otorga todos los permisos al usuario recién creado, limitando su acceso a la base de datos de la aplicación.

* <code>FLUSH PRIVILEGES</code>: Ordena a MariaDB que recargue la tabla de permisos inmediatamente.

==== Paso 4: Preparación del Entorno Python ====

En esta sección se configura el entorno de ejecución del proyecto.

<code>cd $PROJECT_DIR </code>: Navega al directorio raíz del proyecto (/vagrant).

<code>if [ ! -d ".venv" ]; then python3 -m venv .venv; fi </code>: Crea el entorno virtual (.venv) si aún no existe (idempotencia).

<code>source .venv/bin/activate </code>: Activa el entorno virtual. Esto hace que los comandos como pip y flask apunten a los binarios dentro del .venv.

<code>pip install -r requirements.txt </code>: Instala todas las dependencias de Python listadas en el archivo requirements.txt.

==== Paso 5: Migraciones y Creación de Tablas ====

Se utiliza Flask-Migrate (Alembic) para configurar la base de datos con el esquema de modelos de SQLAlchemy.

<code>export FLASK_APP=app.app:create_app</code>: Establece la variable de entorno necesaria para que el comando flask sepa dónde encontrar la instancia de la aplicación (la función create_app en app/app.py).

<code>if [ ! -d "migrations" ]; then flask db init; fi</code>: Comprueba si el directorio migrations existe. Si no, inicializa el repositorio de migraciones de Alembic.

<code>flask db upgrade</code>: Aplica la migración más reciente a la base de datos, lo que resulta en la creación de todas las tablas definidas por los modelos de la aplicación.

==== Paso 6: Lanzamiento de la Aplicación ====

Finalmente, se lanza la aplicación Flask y se sale del entorno de aprovisionamiento.

<code>pkill -f 'flask run --host=0.0.0.0'</code>: Intenta detener cualquier proceso Flask anterior que pudiera estar ejecutándose, asegurando que solo haya una instancia activa.

<code>nohup flask run --host=0.0.0.0 > /tmp/flask_app.log 2>&1 &</code>: Lanza el servidor Flask:

* <code>--host=0.0.0.0</code>: Permite que la aplicación sea accesible desde fuera de la VM (a través del puerto reenviado en Vagrantfile).

* <code> nohup ... &</code>: Ejecuta el comando en segundo plano (&) y lo hace inmune a colgarse (nohup), manteniendo el servidor activo incluso después de que termine la sesión de aprovisionamiento. La salida se redirige al archivo /tmp/flask_app.log.

<code> deactivate</code>: Sale del entorno virtual de Python.

== Iniciar el Entorno Virtual con Vagrant ==
Desde la terminal, navega al directorio `flask_testing_project/` y ejecuta el siguiente comando:
<syntaxhighlight lang="bash">
vagrant up
</syntaxhighlight>

Cuando el proceso finalice, podrás acceder a la aplicación en `http://localhost:5000`.

'''¿Has podido ver qué ocurría en cada paso? ¡Prueba a entrar en la máquina virtual y ver cómo está funcionando todo por dentro!'''

= Parte 2: Aprovisionamiento mediante un playbook de Ansible =

El aprovisionamiento con Ansible ofrece varias ventajas frente al uso de scripts de shell. Mientras que los scripts de shell son imperativos, es decir, detallan los pasos exactos para lograr un objetivo, Ansible adopta un enfoque '''declarativo''', donde especificamos el estado deseado del sistema y Ansible se encarga de llevarlo a cabo. Esto permite una mayor '''idempotencia''', es decir, que la configuración se pueda aplicar varias veces sin causar efectos no deseados. Además, Ansible facilita la gestión de infraestructuras grandes de forma '''escalable y reproducible''', lo que hace que sea más fácil mantener entornos consistentes y automatizados en comparación con los scripts tradicionales. Un aspecto clave de Ansible es que permite aprovisionar diferentes máquinas sin importar el sistema operativo o la infraestructura subyacente, ya que simplemente le indicamos qué necesitamos y Ansible se encarga de implementar la configuración adecuada, independientemente de cómo o dónde se ejecute.

== Paso 1: Modificar el Vagrantfile ==

Modifica el Vagrantfile para ejecutar un playbook de Ansible en lugar del script provision.sh:

<syntaxhighlight lang="ruby">
# Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

# 1. Sistema Operativo
config.vm.box = "ubuntu/jammy64"

# 2. Mapear puerto de Flask (usando 5001 como puerto de host para evitar colisiones)
# Aplicación accesible en http://localhost:5001
config.vm.network "forwarded_port", guest: 5000, host: 5001

# 3. Aprovisionamiento: Ejecuta el Playbook de Ansible
config.vm.provision "ansible" do |ansible|
# Especifica que Vagrant debe ejecutar el archivo playbook.yml
ansible.playbook = "playbook.yml"

# Ejecutar tareas con privilegios de root (sudo)
ansible.become = true

# Asegura que se ejecuta en el host de la MV
ansible.limit = "all"
end
end

</syntaxhighlight>

== Paso 2: Crea el <code>playbook.yml</code> ==

En la raíz del proyecto, al mismo nivel que el Vagrantfile, crea el playbook.yml.

<syntaxhighlight lang="yaml">
---
- name: Configurar Entorno Flask y MariaDB
hosts: all
become: yes # Ejecutar tareas con privilegios de root (sudo)
vars:
project_dir: /vagrant
env_file: "{{ project_dir }}/.env"

tasks:
# --- 1. Saneamiento y Carga de Variables de Entorno (.env) ---
- name: Cargar variables de entorno como JSON y establecer hechos
ansible.builtin.shell: |
# 1. Leer el archivo .env, limpiar CRLF (\r) y líneas vacías/comentarios.
# 2. Convertir el formato KEY=VALUE al formato JSON "KEY":"VALUE".
CLEAN_ENV=$(
cat {{ env_file }} |
tr -d '\r' |
grep -vE '^\s*#' |
grep -vE '^\s*$' |
awk -F'=' '{ gsub(/^[[:space:]]+|[[:space:]]+$/, "", $2); print "\""$1"\":\""$2"\"" }' |
paste -s -d ',' -
)

# 3. Imprimir el JSON completo. Ejemplo: {"KEY1":"VALUE1","KEY1":"VALUE2"}
echo "{ $CLEAN_ENV }"
register: env_output
changed_when: false
tags: [config, env]

- name: Establecer variables de entorno limpias como hechos de Ansible
ansible.builtin.set_fact:
env_vars: "{{ env_output.stdout | from_json }}"
tags: [config, env]

# --- 2. Preparación del Sistema ---
- name: Forzar la actualización del índice de paquetes (apt update)
ansible.builtin.apt:
update_cache: yes
tags: [install, base]

- name: Instalar MariaDB, Python y utilidades necesarias
ansible.builtin.package:
name:
- mariadb-server
- python3-pip
- git
- python3-dev
- python3-venv
state: present
tags: [install, base]

- name: Instalar PyMySQL a nivel de sistema (Necesario para los módulos 'mysql_*' de Ansible)
ansible.builtin.pip:
name: pymysql
executable: pip3
tags: [install, db]

# --- 3. Configuración de MariaDB (Módulos declarativos de MySQL) ---
- name: Asegurar que el servicio MariaDB esté iniciado y habilitado
ansible.builtin.service:
name: mariadb
state: started
enabled: yes
tags: [db]

- name: Crear Base de Datos y Usuario
block:
- name: Crear Base de Datos
community.mysql.mysql_db:
name: "{{ env_vars.DATABASE_DB }}"
state: present
encoding: utf8mb4
collation: utf8mb4_unicode_ci
login_unix_socket: /run/mysqld/mysqld.sock
tags: [db]

- name: Crear Usuario de Aplicación y Otorgar Permisos
community.mysql.mysql_user:
name: "{{ env_vars.DATABASE_USER }}"
password: "{{ env_vars.DATABASE_PASSWORD }}"
host: "localhost"
priv: "{{ env_vars.DATABASE_DB }}.*:ALL"
state: present
login_unix_socket: /run/mysqld/mysqld.sock
tags: [db]

# --- 4. Configuración de la Aplicación Flask ---
- name: Instalar dependencias de Python a nivel de sistema
ansible.builtin.pip:
requirements: "{{ project_dir }}/requirements.txt"
executable: pip3 # Usamos pip3 del sistema
state: present
tags: [app, install]

- name: Aplicar migraciones de base de datos (Flask-Migrate)
ansible.builtin.command: python3 -m flask db upgrade # Usamos python3 -m flask
environment:
DATABASE_USER: "{{ env_vars.DATABASE_USER }}"
DATABASE_PASSWORD: "{{ env_vars.DATABASE_PASSWORD }}"
DATABASE_DB: "{{ env_vars.DATABASE_DB }}"
DATABASE_HOST: "{{ env_vars.DATABASE_HOST | default('localhost') }}"
FLASK_APP: app.app:create_app
args:
chdir: "{{ project_dir }}"
become: yes
become_user: vagrant
tags: [app, db]

# --- 5. Lanzar la Aplicación ---

# Tarea 5.1: Detener procesos previos
- name: Detener instancias de Flask previamente en ejecución
ansible.builtin.shell: "pkill -f 'python3 -m flask run --host=0.0.0.0'"
become: yes
become_user: vagrant
failed_when: false # CRÍTICO: Ignorar el error si pkill no encuentra nada.
tags: [app, run]

# Tarea 5.2: Iniciar Flask en segundo plano con nohup
- name: Iniciar Flask en segundo plano con nohup
ansible.builtin.shell: |
nohup python3 -m flask run --host=0.0.0.0 > /tmp/flask_app.log 2>&1 &
environment:
FLASK_APP: app.app:create_app
DATABASE_USER: "{{ env_vars.DATABASE_USER }}"
DATABASE_PASSWORD: "{{ env_vars.DATABASE_PASSWORD }}"
DATABASE_DB: "{{ env_vars.DATABASE_DB }}"
DATABASE_HOST: "{{ env_vars.DATABASE_HOST | default('localhost') }}"
args:
chdir: "{{ project_dir }}"
become: yes
become_user: vagrant
tags: [app, run]

- name: Verificar que Flask se esté ejecutando
ansible.builtin.shell: "ps aux | grep -v grep | grep 'python3 -m flask run --host=0.0.0.0'"
register: flask_status
failed_when: flask_status.rc != 0 and 'python3 -m flask run' not in flask_status.stdout
tags: [app, run]

- name: Mostrar mensaje de acceso
ansible.builtin.debug:
msg: "✅ ¡Aprovisionamiento COMPLETO! La aplicación Flask está en segundo plano. Acceda en http://localhost:5001"
tags: [app, run]

</syntaxhighlight>

=== Paso 2: Explicación detallada del <code>playbook.yml</code> ===

==== Carga y Saneamiento de Variables ====

Este bloque es fundamental para la estabilidad. Resuelve los problemas de caracteres invisibles del archivo <code>.env</code> que suelen causar fallos en MariaDB, cargando las variables en un formato JSON limpio.

Ansible lee el archivo <code>/vagrant/.env</code>, utiliza herramientas de shell como <code>tr</code> y <code>awk</code> para eliminar cualquier carácter de retorno de carro (CRLF) o espacio sobrante, y lo formatea como un objeto JSON.

El módulo <code>set_fact</code> carga este JSON limpio en la variable <code>env_vars</code>, garantizando que nombres como la base de datos y el usuario sean cadenas de texto perfectas.

==== Instalación de Componentes Base ====

Esta sección configura el sistema operativo para ejecutar la base de datos y la aplicación Python.

<code>sudo apt update</code>: Se fuerza la actualización del índice de paquetes para asegurar que se instalen las versiones más recientes.

<code>sudo apt install mariadb-server python3-pip python3-dev ...</code>: Instala todos los paquetes necesarios del sistema: el servidor de MariaDB, las herramientas de Python 3, y las cabeceras de desarrollo de Python (<code>python3-dev</code>), que son necesarias para compilar bibliotecas binarias como mysqlclient.

<code>pip3 install pymysql</code>: Instala la biblioteca PyMySQL a nivel de sistema. Esta biblioteca no es para la aplicación Flask, sino para que Ansible pueda comunicarse con MariaDB y crear la base de datos y el usuario en las siguientes tareas.

==== Configuración de MariaDB ====

Este bloque configura la base de datos y el usuario de manera idempotente utilizando los módulos declarativos de Ansible, que reemplazan la necesidad de ejecutar comandos SQL manuales.

La tarea <code>Asegurar que el servicio MariaDB esté iniciado y habilitado</code> equivale a:
<code>sudo systemctl enable mariadb / sudo systemctl start mariadb</code>: Asegura que el servicio MariaDB esté habilitado para arrancar con el sistema y lo inicia inmediatamente.

La tarea <code>Crear Base de Datos</code> utiliza el valor limpio de <code>DATABASE_DB</code> para crearla con la codificación correcta (utf8mb4).

La tarea <code>Crear Usuario de Aplicación y Otorgar Permisos</code> utiliza los valores limpios de <code>DATABASE_USER</code> y <code>DATABASE_PASSWORD</code> para crear el usuario y otorgarle todos los permisos (<code>GRANT ALL PRIVILEGES</code>) sobre la base de datos recién creada.

==== Instalación de Dependencias Python ====

La tarea <code>Instalar dependencias de Python a nivel de sistema</code> equivale a:
<code>sudo pip3 install -r /vagrant/requirements.txt</code>: Instala todas las dependencias listadas en el archivo <code>requirements.txt</code> a nivel global del sistema.

==== Migraciones y Creación de Tablas ====

Se utiliza Flask-Migrate para configurar la base de datos con el esquema de modelos de SQLAlchemy.

La tarea <code>Aplicar migraciones de base de datos (Flask-Migrate)</code> ejecuta el comando: <code>export FLASK_APP=app.app:create_app</code>

<code>python3 -m flask db upgrade</code>: Aplica la migración más reciente a la base de datos, creando todas las tablas definidas por los modelos de la aplicación (o actualizándolas si ya existen). Esta tarea se ejecuta como el usuario <code>vagrant</code> para asegurar los permisos de acceso a los archivos del proyecto.

==== Lanzamiento de la Aplicación ====

Finalmente, se lanza la aplicación Flask y se asegura su continuidad.

La tarea <code>Detener instancias de Flask previamente en ejecución</code> ejecuta:
<code>pkill -f 'python3 -m flask run --host=0.0.0.0'</code>: Intenta detener cualquier proceso Flask anterior. Es crucial que la tarea tenga la opción <code>failed_when: false</code>, para que Ansible no falle si no se encuentra ningún proceso que matar.

La tarea <code>Iniciar Flask en segundo plano con nohup</code> ejecuta:
<code>nohup python3 -m flask run --host=0.0.0.0 > /tmp/flask_app.log 2>&1 &</code>: Lanza el servidor Flask:

<code>--host=0.0.0.0</code>: Permite que la aplicación sea accesible desde fuera de la VM (a través del puerto reenviado en Vagrantfile).

<code>nohup ... &</code>: Ejecuta el comando en segundo plano (<code>&</code>) y lo hace inmune a colgarse (<code>nohup</code>), manteniendo el servidor activo. La salida se redirige al archivo <code>/tmp/flask_app.log</code>.

Verificación y Mensaje Final: Las últimas tareas verifican que el proceso Flask esté corriendo y muestran un mensaje de éxito, indicando que la aplicación está lista en <code>http://localhost:5001</code>.

La aplicación Flask estará disponible en `http://localhost:5001` cuando finalice el aprovisionamiento.

'''¿Qué has podido observar ahora en la terminal en la etapa de aprovisionamiento? ¿Crees que la MV estará funcionando igual que en el aprovisionamiento por shell script?'''

=Conclusión=

Este tutorial te ha guiado a través de dos métodos de aprovisionamiento de una aplicación Flask en Vagrant, utilizando un script de shell y un playbook de Ansible. ¡Ahora deberías tener una mejor comprensión del aprovisionamiento automático y de cómo desplegar aplicaciones en entornos virtuales reproducibles!

¡Enhorabuena si has llegado hasta aquí! Y, recuerda, las máquinas virtuales consumen recursos de tu equipo, apágalas y elimínalas cuando ya no las necesites.

Archivo:EGC 2025-26 P6.pdf

2025-11-18T06:16:47Z

Jmorenol: Jmorenol subió una nueva versión de Archivo:EGC 2025-26 P6.pdf

Prácticas - 25/26

2025-11-18T05:49:31Z

Jmorenol:

[[Página_Principal]] -> [[2025/2026]] -> [[Prácticas - 25/26]]

== Prácticas ==

* Práctica 1: '''Instalación del sistema base''' [[Archivo:EGC 2025-26 P1.pdf]]
* Práctica 2: '''Integración y despliegue continuos ''' [[Archivo:EGC 2025-26 P2.pdf]]
** [[Workflows solución P2 2526 |Workflows solución para los ejercicios propuestos]]
* Práctica 3: '''Gestión del código fuente''' [[Archivo:EGC_2025-26_P3.pdf]]
** Solución ejercicios alumno/a A: [[Archivo:P3 usuario A 2526.pdf]]
** Solución ejercicios alumno/a B: [[Archivo:P3 usuario B 2526.pdf]]
* Práctica 4: '''Automatización de pruebas''' [[Archivo:EGC_2025-26_P4.pdf]]
* Práctica 5: '''Contenedores, dev-containers y aislamiento''' [[Archivo:EGC_2025-26_P5.pdf]]
*Práctica 6: '''Máquinas virtuales y aprovisionamiento''' [[Archivo:EGC 2025-26 P6.pdf ]]
** Campo de entrenamiento de Vagrant: [[Tutorial Campo de entrenamiento de Vagrant]]
** Tutorial configurando una máquina virtual para una aplicación: [[Tutorial configurando vagrant para una aplicación 2526|Tutorial configurando vagrant para una aplicación]]
** ¡Ahora es el momento de probar con uvlhub! [https://docs.uvlhub.io/installation/installation_with_vagrant]

----

==== Material adicional para el desarrollo de las sesiones prácticas ====

* Box con la imagen de Ubuntu de los equipos de laboratorio de prácticas : [https://portal.cloud.hashicorp.com/vagrant/discover/cdcetsii/UbuntuEGC_25]

Prácticas - 25/26

2025-10-28T07:17:18Z

Jmorenol: /* Prácticas */

Archivo:EGC 2025-26 P5.pdf

2025-10-28T07:16:58Z

Jmorenol:

Tutorial-docker

2025-10-28T07:12:59Z

Jmorenol: /* Orquestación básica */

= Ejercicio 1: Empezamos desde cero =

El objetivo es eliminar toda la configuración previa y crear desde cero la estructura de carpetas que contendrá nuestros futuros archivos Docker.

== Eliminar la configuración existente ==
Antes de comenzar, asegúrate de borrar cualquier carpeta Docker existente en el proyecto. En este caso, le haremos una copia de seguridad para poder volver a ella.

<syntaxhighlight lang="bash">
mv docker docker.bk
</syntaxhighlight>

También debes asegurarte que trabajas con las variables de entorno adecuadas:

<syntaxhighlight lang="bash">
cp .env.docker.example .env
</syntaxhighlight>

⚠️ Este paso es importante: partimos completamente desde cero para entender cada parte del sistema.

== Instalar Docker y Docker Compose (Linux) ==

<syntaxhighlight lang="bash">
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce
sudo usermod -aG docker ${USER}
mkdir -p ~/.docker/cli-plugins/
LATEST_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep '"tag_name":' | sed -E 's/.*"([^"]+)".*/\1/')
curl -SL "https://github.com/docker/compose/releases/download/${LATEST_VERSION}/docker-compose-$(uname -s)-$(uname -m)" -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose
</syntaxhighlight>

Es posible que tengas que reiniciar la sesión de usuario para poder usar docker sin necesidad de sudo.

== Crear un Dockerfile mínimo ==

Ahora crea nuevamente la carpeta base donde almacenaremos los archivos relacionados con Docker:

<syntaxhighlight lang="bash"> mkdir -p docker/images </syntaxhighlight>

Creamos un Dockerfile vacío

<syntaxhighlight lang="dockerfile">
touch docker/images/Dockerfile
</syntaxhighlight>

Vamos a explicar los distintos apartados:

=== FROM ===
<syntaxhighlight lang="dockerfile">
FROM python:3.12-slim
</syntaxhighlight>

Indica la imagen base sobre la que se construirá la tuya.
En este caso, parte de una imagen ligera que ya tiene Python 3.12 instalado.

=== WORKDIR ===
<syntaxhighlight lang="dockerfile">
WORKDIR /app
</syntaxhighlight>

Esta línea define el directorio de trabajo dentro del contenedor.
A partir de aquí, todos los comandos que aparezcan después (COPY, RUN, CMD, etc.) se ejecutarán dentro de /app.

'''Ojo: /app no es la carpeta app/ de tu proyecto local.'''. Son cosas distintas.

En tu máquina puede existir algo como:

<syntaxhighlight lang="text">
uvlhub
app
core
requirements.txt
</syntaxhighlight>

Pero dentro del contenedor la estructura será distinta:

<syntaxhighlight lang="text">
/
app/
app/ ← aquí dentro se habrá copiado tu carpeta local "app"
</syntaxhighlight>

Cuando más adelante uses:

<syntaxhighlight lang="dockerfile">
COPY . .
</syntaxhighlight>

Docker copiará todos los archivos de tu proyecto dentro de la carpeta /app del contenedor.
Por eso el código quedará en /app/app/.

=== COPY ===
<syntaxhighlight lang="dockerfile">
COPY . .
</syntaxhighlight>

Copia todos los archivos del proyecto (del host) dentro del contenedor, en /app.
El primer punto es el origen; el segundo, el destino.

=== RUN ===
<syntaxhighlight lang="dockerfile">
RUN pip install --no-cache-dir -r requirements.txt
</syntaxhighlight>

Ejecuta comandos durante la construcción de la imagen.
Aquí instalamos las dependencias necesarias desde requirements.txt.
El resultado de este paso quedará guardado en la imagen.

=== EXPOSE ===
<syntaxhighlight lang="dockerfile">
EXPOSE 5000
</syntaxhighlight>

Documenta el puerto que la aplicación usa dentro del contenedor.
Esto no lo abre al exterior; simplemente indica que la app escucha en el 5000.

=== CMD ===
<syntaxhighlight lang="dockerfile">
CMD ["flask", "run", "--host=0.0.0.0", "--port=5000", "--reload", "--debug"]
</syntaxhighlight>

Define el comando que se ejecutará cuando el contenedor se inicie.
En este caso, ejecutará la aplicación Flask.

=== RUN vs CMD ===

Estas dos instrucciones parecen similares, pero hacen cosas muy distintas.

==== RUN ====
Se ejecuta durante la construcción de la imagen (en el momento del docker build).
Cada RUN crea una nueva capa dentro de la imagen.

Ejemplo:

<syntaxhighlight lang="dockerfile">
RUN pip install -r requirements.txt
</syntaxhighlight>

Este comando instala las dependencias una sola vez, cuando se construye la imagen.
El resultado (las librerías instaladas) queda grabado dentro de la imagen final.

Si después lanzas un contenedor nuevo a partir de esa imagen, las dependencias ya estarán instaladas y no se volverán a ejecutar.

==== CMD ====
Se ejecuta cuando se inicia el contenedor (en el docker run).
Define el proceso principal que se ejecutará dentro del contenedor mientras esté activo.

Ejemplo:

<syntaxhighlight lang="dockerfile">
CMD ["flask", "run", "--host=0.0.0.0", "--port=5000"]
</syntaxhighlight>

Este comando no se ejecuta durante la construcción, sino cada vez que arrancas el contenedor.
Si detienes el contenedor, este proceso también se detiene.

==== Diferencia resumida ====

RUN → se ejecuta al construir la imagen (fase de docker build).

CMD → se ejecuta al iniciar el contenedor (fase de docker run).

Solo puede haber un CMD por Dockerfile.
Si hay más de uno, solo se usará el último.

== Dockerfile completo ==
<syntaxhighlight lang="dockerfile">
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
EXPOSE 5000
CMD ["flask", "run", "--host=0.0.0.0", "--port=5000", "--reload", "--debug"]
</syntaxhighlight>

Esto tiene que ir en un Dockerfile en docker/images

== Construir la imagen ==
Desde la raíz del proyecto (no dentro de docker/images):

<syntaxhighlight lang="bash">
docker build -t uvlhub:dev -f docker/images/Dockerfile .
</syntaxhighlight>

== Ejecutar el contenedor ==

<syntaxhighlight lang="bash">
docker run -p 5000:5000 uvlhub:dev
</syntaxhighlight>

Abre el navegador en [http://localhost:5000 http://localhost:5000]. ¿Qué es lo que observas?

= Ejercicio 2: Conectando servicios =

¡Vaya! ¡No funciona! Can't connect to MySQL server on 'db'... ¡Ah, claro, intenta conectarse a la base de datos, que no lo tenemos! Pero claro, en un contenedor no es recomendable tener la app y la base de datos conviviendo...

== Crear contenedor MariaDB ==

Antes que nada, haz Ctrl + C para parar el contenedor web. En este ejercicio aprenderás a lanzar un contenedor de MariaDB 12.0.2 de forma manual, configurando todas las variables necesarias para tu aplicación Flask.

El objetivo es entender la complejidad de hacerlo “a mano”, antes de automatizarlo con docker-compose.

== Descargar la imagen oficial ==
Primero descarga la versión exacta que usaremos:

<syntaxhighlight lang="bash">
docker pull mariadb:12.0.2
</syntaxhighlight>

== Crear el contenedor de MariaDB ==
Lanza un contenedor con todas las variables necesarias para que Flask pueda conectarse correctamente:

<syntaxhighlight lang="bash">
docker run -d --name mariadb_container \
-e FLASK_APP_NAME="UVLHUB.IO(dev)" \
-e FLASK_ENV=development \
-e DOMAIN=localhost \
-e MARIADB_HOSTNAME=db \
-e MARIADB_PORT=3306 \
-e MARIADB_DATABASE=uvlhubdb \
-e MARIADB_TEST_DATABASE=uvlhubdb_test \
-e MARIADB_USER=uvlhubdb_user \
-e MARIADB_PASSWORD=uvlhubdb_password \
-e MARIADB_ROOT_PASSWORD=uvlhubdb_root_password \
-e WORKING_DIR=/app/ \
-p 3306:3306 mariadb:12.0.2
</syntaxhighlight>

Explicación:

* -d: ejecuta el contenedor en segundo plano (modo detached).
* --name: asigna un nombre identificable al contenedor.
* -e: define variables de entorno dentro del contenedor.
* -p 3306:3306: publica el puerto de MariaDB en tu máquina local.
* mariadb:12.0.2: imagen exacta que vamos a usar.

Aquí ya, de entrada, vemos que esto es más feo que una nevera por detrás. Para empezar, estamos pasando a lo loco un montón de variables que difílmente será replicable en producción, por contener información sensible. Aparte, si metemos nuevas variables, ese comando queda inservible. Necesitaremos una solución más ágil para este problema

== Comprobar que está corriendo ==
<syntaxhighlight lang="bash">
docker ps
</syntaxhighlight>

Deberías ver algo así:

<syntaxhighlight lang="text">
CONTAINER ID IMAGE COMMAND STATUS PORTS NAMES
abcd1234efgh mariadb:12.0.2 "docker-entrypoint.s…" Up 5 seconds 0.0.0.0:3306->3306/tcp mariadb_container
</syntaxhighlight>

== Conectarse a la base de datos ==
Abre una consola dentro del contenedor:

<syntaxhighlight lang="bash">
docker exec -it mariadb_container bash
</syntaxhighlight>

Y dentro, accede al cliente de MariaDB:

<syntaxhighlight lang="bash">
mariadb -u root -p
</syntaxhighlight>

Contraseña: uvlhubdb_root_password

== Verificar la base de datos ==
Una vez dentro del cliente MySQL, ejecuta:

<syntaxhighlight lang="sql">
SHOW DATABASES;
</syntaxhighlight>

Deberías ver que existen la bases de datos uvlhubdb porque pedimos crearla a la hora de levantar el contenedor. ¿Qué tiene la base de datos dentro? Vamos a verlo...

<syntaxhighlight lang="sql">
USE uvlhubdb;
SHOW TABLES;
</syntaxhighlight>

Un total de... 0 tablas... ¡Claro! Es que solo hemos creado la base en sí, pero no las tablas. ¿Con un script SQL tal vez? ¡Espera, espera, si tenemos las migraciones! Pero claro, para eso necesito el contenedor de la app levantado. Sal de la consola SQL y del contenedor de MariaDB. Bien, ahora en el host...

<syntaxhighlight lang="bash">
docker run -p 5000:5000 -d uvlhub:dev
</syntaxhighlight>

Esta vez con el flag "-d" para que corra en segundo plano. Ahora, accedamos al contenedor y ejecutemos las migraciones. Pero... ¿cómo se llama mi contenedor?

<syntaxhighlight lang="bash">
docker ps
</syntaxhighlight>

Fíjate que Docker asigna un nombre aleatorio a tu contenedor web porque no definiste ninguno. Una vez identificado el nombre:

<syntaxhighlight lang="bash">
docker exec -it <nombre> bash
flask db upgrade
</syntaxhighlight>

What? ¿Qué pasa? ¿Otra vez error de conexión con la base? Si tenemos el contenedor funcionando, esto es un jaleo...

== Redes internas ==

Ahora mismo tienes dos contenedores aislados, el de la app y el la base de datos. Por defecto, cada contenedor tiene su propia red interna y no puede ver a los demás por nombre. El hostname '''db''' que usa Flask no existe en su DNS interno.

=== Conectar servicios ===

Vamos a crear una red interna que compartan ambos contenedores

<syntaxhighlight lang="bash">
docker network create uvlhub_network
docker network ls
</syntaxhighlight>

Vemos que ya aparece nuestra red '''uvlhub_network'''. Ahora, conectemos el contenedor de MariaDB a la red:

<syntaxhighlight lang="bash">
docker stop mariadb_container
docker rm mariadb_container
</syntaxhighlight>

<syntaxhighlight lang="bash">
docker run -d \
--name mariadb_container \
--hostname db \
--network uvlhub_network \
-e FLASK_APP_NAME="UVLHUB.IO(dev)" \
-e FLASK_ENV=development \
-e DOMAIN=localhost \
-e MARIADB_HOSTNAME=db \
-e MARIADB_PORT=3306 \
-e MARIADB_DATABASE=uvlhubdb \
-e MARIADB_TEST_DATABASE=uvlhubdb_test \
-e MARIADB_USER=uvlhubdb_user \
-e MARIADB_PASSWORD=uvlhubdb_password \
-e MARIADB_ROOT_PASSWORD=uvlhubdb_root_password \
-e WORKING_DIR=/app/ \
-p 3306:3306 \
mariadb:12.0.2
</syntaxhighlight>

Claro, si te fijas, ahora hay que añadir, además de toda esa configuración engorrosa, que se añada en la misma red y que además tenga de hostname "db" para que el contenedor web entienda qué es "db". Tenemos que hacer lo mismo para el contenedor web:

<syntaxhighlight lang="bash">
docker stop <nombre>
docker rm <nombre>
</syntaxhighlight>

Y lo levantamos de nuevo, pero ya en la nueva red. De paso, le ponemos un nombre para identificarlo mejor.

<syntaxhighlight lang="bash">
docker run -p 5000:5000 --name web_app_container --network uvlhub_network -d uvlhub:dev
</syntaxhighlight>

Y ahora ya podemos acceder al contenedor por su nombre y ejecutar las migraciones:

<syntaxhighlight lang="bash">
docker exec -it web_app_container bash
flask db upgrade
</syntaxhighlight>

Abre el navegador en [http://localhost:5000 http://localhost:5000]. ¿Mejor?

= Ejercicio 3: Persistencia =

Vamos a simular que hemos desplegado justo esto en producción y el servidor se reinicia por un corte de luz. Reiniciemos a mano cada contenedor:

<syntaxhighlight lang="bash">
docker restart web_app_container
docker restart mariadb_container
</syntaxhighlight>

Abre de nuevo [http://localhost:5000 http://localhost:5000]. What? ¿Cómo? ¿Qué ha pasado? ¿Otra vez problema de conexión? Ve dándole a F5... F5... ¡bingo! Ahora sí sale, pero menuda aleatoriedad, ¿no? Claro, es que ahora caes en que una cosa es que el contenedor haya arrancado y otra que esté listo.

Aparte, tenemos otro problema. ¿Qué pasa con la persistencia? Porque si borro el contenedor de MariaDB, todos los datos que estén en su interior también se pierden. Y si estamos en producción, lío asegurado.

== Volúmenes ==

Cada vez que eliminas el contenedor de MariaDB, todas las bases de datos se pierden. Esto ocurre porque los datos se guardan dentro del sistema de archivos del contenedor, y al borrarlo desaparecen con él.

En este ejercicio creas un volumen de Docker para que los datos persistan entre ejecuciones.

=== Crear un volumen ===
Un volumen es una carpeta gestionada por Docker que vive fuera del ciclo de vida de los contenedores.

Ejecuta:

<syntaxhighlight lang="bash">
docker volume create mariadb_data
</syntaxhighlight>

Comprueba que existe:

<syntaxhighlight lang="bash">
docker volume ls
</syntaxhighlight>

La salida muestra algo como:

<syntaxhighlight lang="bash">
DRIVER VOLUME NAME
local mariadb_data
</syntaxhighlight>

=== Crear un contenedor de MariaDB con el volumen ===
Lanza el contenedor y conecta el volumen a la ruta donde MariaDB guarda los datos (/var/lib/mysql):

<syntaxhighlight lang="bash">
docker stop mariadb_container
docker rm mariadb_container
docker run -d \
--name mariadb_container \
--hostname db \
--network uvlhub_network \
-v mariadb_data:/var/lib/mysql \
-e FLASK_APP_NAME="UVLHUB.IO(dev)" \
-e FLASK_ENV=development \
-e DOMAIN=localhost \
-e MARIADB_HOSTNAME=db \
-e MARIADB_PORT=3306 \
-e MARIADB_DATABASE=uvlhubdb \
-e MARIADB_TEST_DATABASE=uvlhubdb_test \
-e MARIADB_USER=uvlhubdb_user \
-e MARIADB_PASSWORD=uvlhubdb_password \
-e MARIADB_ROOT_PASSWORD=uvlhubdb_root_password \
-e WORKING_DIR=/app/ \
-p 3306:3306 \
mariadb:12.0.2
</syntaxhighlight>

== Qué significa ":" en los volúmenes ===

Cuando usas la opción '''-v''' o '''--volume''' en Docker, el signo dos puntos (''':''') separa dos rutas:

'''-v origen:destino'''

origen → es la ruta o el volumen en tu máquina (el host).

destino → es la ruta dentro del contenedor.

= Ejercicio 4: Orquestación de servicios =

Hasta ahora hemos creado y conectado los contenedores manualmente.
Ahora vas a usar Docker Compose para definir todo en un solo archivo.

Lo primero es parar y eliminar los contenedores previos para que no interfieran:

<syntaxhighlight lang="bash">
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
</syntaxhighlight>

== Orquestación básica ==

Crea un archivo llamado docker-compose.yml en la carpeta '''docker''' con este contenido:

<syntaxhighlight lang="bash">
services:
web:
container_name: web_app_container
env_file:
- ../.env
expose:
- "5000"
depends_on:
- db
build:
context: ../
dockerfile: docker/images/Dockerfile
networks:
- uvlhub_network

db:
container_name: mariadb_container
image: mariadb:12.0.2
env_file:
- ../.env
volumes:
- db_data:/var/lib/mysql
networks:
- uvlhub_network

volumes:
db_data:

networks:
uvlhub_network:
</syntaxhighlight>

Fíjate que esta orquestación de servicios me permite definir el nombre de cada servicio, su dependencia, sus puertos, sus volúmenes, redes... todo lo que hacíamos de forma manual y propenso a errores queda ahora más fácil de gestionar. Además, ahora ambos contenedores comparten el mismo archivo .env de variables de entorno.

Bien, ahora vamos a levantar estos contenedores y acceder al contenedor web:

<syntaxhighlight lang="bash">
docker compose -f docker/docker-compose.yml up -d --build
docker exec -it web_app_container bash
</syntaxhighlight>

Inmediatamente después, ejecuta las migraciones:

<syntaxhighlight lang="bash">
flask db upgrade
</syntaxhighlight>

¿Qué ha ocurrido? Depende del tiempo que hayas tardado, puede que haya saltado un error o puede que haya funcionado. Puede que hayas intentado varias veces el comando anterior hasta que ha funcionado. ¿Por qué crees que ocurre esta aparente aleatoriedad?

== Dependencias entre contenedores y entrypoints ==

Fíjate que tenemos un "depends on" en el servicio web. Significa que el servicio "db" debe iniciarse antes que el servicio web. Pero, cuidado, ahí está la trampa, porque "servicio iniciado != servicio preparado". El servicio de MariaDB tiene que arrancar, configurarse, etc...

Cuando hicimos el comando COPY en nuestro Dockerfile, también copiamos la carpeta '''scripts'''. Uno de los scripts es '''wait-for-db.sh''', que realiza continuamente llamadas a MariaDB hasta que este servicio está listo para recibir peticiones. Ábrelo y estúdialo.

Añade al servicio web de tu docker compose las siguientes líneas:

<syntaxhighlight lang="bash">
entrypoint: ["/app/scripts/wait-for-db.sh"]
command: ["flask", "run", "--host=0.0.0.0", "--port=5000", "--reload", "--debug"]
</syntaxhighlight>

A su vez, del Dockerfile, hay que eliminar la línea de CMD que arrancaba nuestro servidor Flask.

Luego, reinicializa todos los servicios:

<syntaxhighlight lang="bash">
docker compose -f docker/docker-compose.yml down
docker compose -f docker/docker-compose.yml up -d --build
</syntaxhighlight>

Abre de nuevo [http://localhost:5000 http://localhost:5000]. What? ¿No abre? Vamos a investigarlo, veamos el logs:

<syntaxhighlight lang="bash">
docker logs web_app_container
</syntaxhighlight>

Nos debe salir un mensaje eterno de "/app/scripts/wait-for-db.sh: line 18: mariadb: command not found". Esto ocurre porque en la imagen de nuestro servicio web NO TENEMOS el cliente de MariaDB. Debemos indicar entonces que lo instale. Añade justo debajo de FROM lo siguiente:

<syntaxhighlight lang="bash">
RUN apt-get update && apt-get install -y --no-install-recommends mariadb-client
</syntaxhighlight>

Al ser un contenedor basado en Linux, y accediendo como root, es como si actualizáramos todos los paquetes y luego instalásemos el cliente de MariaDB. Intentémoslo otra vez:

<syntaxhighlight lang="bash">
docker compose -f docker/docker-compose.yml down
docker compose -f docker/docker-compose.yml up -d --build
</syntaxhighlight>

Abre de nuevo [http://localhost:5000 http://localhost:5000]. ¡Jopelines! ¿Tampoco? Si haces un "docker ps" verás el problema. El contenedor web no tiene expuesto ningún puerto.

<syntaxhighlight lang="bash">
services:
web:
(...)
expose:
- "5000"
(...)
</syntaxhighlight>

"Expose" hace visible el puerto '''entre contenedores''', pero '''NO entre tu contenedor y el host'''. Para eso usamos la directiva "ports", que se encarga del mapping. En nuestro caso, será:

<syntaxhighlight lang="bash">
services:
web:
(...)
ports:
- "5000:5000"
(...)
</syntaxhighlight>

En ocasiones, si los dos puertos coinciden, se puede dejar uno solo con "5000" pero dejaremos los dos. El de la izquierda siempre es el puerto externo (host), el de la derecha es el puerto interno (contenedor). Así que cambia ese detalle y por última vez:

<syntaxhighlight lang="bash">
docker compose -f docker/docker-compose.yml down
docker compose -f docker/docker-compose.yml up -d --build
</syntaxhighlight>

Recuerda ejecutar las migraciones:

<syntaxhighlight lang="bash">
docker exec -it web_app_container bash
flask db upgrade
exit
</syntaxhighlight>

Ten en cuenta que si falla, es porque la base aún no está lista, para eso tenemos el script... Y, ya que estamos, ¿se te ocurre alguna forma de automatizar este proceso? Es decir, que yo levante los contenedores y realice también las migraciones de la base de datos.

Abre de nuevo [http://localhost:5000 http://localhost:5000]. ¡Ahora sí!

== Trabajando con CMD, entrypoints y commands ==

Piensa que al arrancar un contenedor Docker, siempre se ejecuta un único comando final.
Lo que hacen ENTRYPOINT, CMD y command (de Compose) es decidir qué comando será ese y con qué argumentos.

=== CMD → “qué hacer por defecto” ===

* Está en el Dockerfile.
* Es el comando que Docker ejecuta si no se indica otra cosa. En nuestro caso:

<syntaxhighlight lang="bash">
CMD ["flask", "run", "--host=0.0.0.0", "--port=5000", "--reload", "--debug"]
</syntaxhighlight>

=== ENTRYPOINT → “qué se ejecuta siempre” ===

* También va en el Dockerfile, o se puede sobreescribir en el docker-compose.yml.
* Define el programa o script principal que siempre se ejecuta.

<syntaxhighlight lang="bash">
ENTRYPOINT ["/app/scripts/wait-for-db.sh"]
CMD ["flask", "run", "--host=0.0.0.0", "--port=5000"]
</syntaxhighlight>

Normalmente, el entrypoint se combina con CMD en modo "eh, ejecuta esto (entrypoint) y luego este comando final (cmd)

Los entrypoints son muy útiles, sobre todo en los docker-compose's, porque puedo redefinir cómo quiero que inicie un contenedor en concreto '''SIN TENER QUE HACER UN BUILD DE NUEVO DE LA IMAGEN DE DOCKER'''. A diferencia de CMD, que viene predefinido, un entrypoint en mi docker-compose me da más versatilidad

=== command (de docker-compose.yml) → “sobrescribe el CMD” ===

En docker-compose.yml, el campo command: reemplaza al CMD del Dockerfile,pero no al ENTRYPOINT.

== Combinación de elementos ==

Es importante entender cómo Docker trabaja con la orquestación y con los contenedores:

* Lee el YAML como un diccionario
* Ejecuta todo lo que haya en un Dockerfile EXCEPTUANDO directivas ENTRYPOINT y CMD
* Monta el volumen o los volúmenes de ese contenedor (si procede)

Y ahora viene el detalle:

* Si estamos levantando un contenedor a través de docker-compose, va a ejecutar los entrypoints y commands definidos en ese docker-compose.
* Un entrypoint definido en un docker-compose va a sustituir a un entrypoint definido en el Dockerfile
* Un command definido en un docker-compose va a sustituir a un CMD definido en el Dockerfile.

Como consejo:

* Definimos un entrypoint en el docker-compose. Esto es así porque está fuera de la imagen de Docker y nos permite redefinir el inicio del servicio sin modificar la imagen
* Eventualmente, definimos un CMD donde indicamos el comando final de ese contenedor al iniciar, que suele ser el arranque de Flask Server o de Gunicorn, dependiendo de si estamos en desarrollo o producción.

No obstante, como nuestros entrypoints son todos scripts en bash, podemos definir en el mismo el arranque final (comando final) y nos olvidamos de CMD.

= Ejercicio 5: Volumen de trabajo =

== Problema de desarrollo ==

Vale, ya parece que le hemos pillado el tranquillo a Docker y a Docker Compose. Ahora vamos a hacer algo como desarrolladores. Ve al archivo "app/templates/base_templates.html" y cambia la línea 22:

<syntaxhighlight lang="bash">
<title>{{ FLASK_APP_NAME }} - Repository of feature models in UVL </title>
</syntaxhighlight>

por:

<syntaxhighlight lang="bash">
<title>Hello world! </title>
</syntaxhighlight>

Abre [http://localhost:5000 http://localhost:5000]. Fíjate en el nombre de la pestaña del navegador, ¿ha cambiado? ¿No? Tsss, esto de los contenedores... bueno, va, vamos a reiniciarlo:

<syntaxhighlight lang="bash">
docker restart web_app_container
</syntaxhighlight>

Abre [http://localhost:5000 http://localhost:5000]. ¿Tampoco? Anda que vaya idea la de usar Docker... Claro, es a la hora de construir la imagen, hicimos "COPY . .", pero no hemos reconstruido nada, así que...

<syntaxhighlight lang="bash">
docker compose -f docker/docker-compose.yml build --no-cache web
docker compose -f docker/docker-compose.yml up -d --force-recreate web
</syntaxhighlight>

Importante señalar que le pedimos que ignore la caché para que fuerce a copiar de nuevo todo el contenido (incluyendo el cambio de línea) al interior del contenedor.

Abre [http://localhost:5000 http://localhost:5000]. ¡Ahora sí! Pero... ¿tengo que reconstruir TODO el contenedor en cada cambio línea? ¿Y eso es trabajar de forma ágil?

== Crear volumen de trabajo (bind mount) ==

Evidentemente, eso no tiene sentido, tenemos que usar un volumen de trabajo que nos ayude a sincronizar el código de nuestro host con el código interno del contenedor. Luego en nuestro docker-compose:

<syntaxhighlight lang="bash">
web:
(....)
ports:
- "5000:5000"
volumes:
- ../:/app
(....)
</syntaxhighlight>

La línea

<syntaxhighlight lang="bash">
- ../:/app
</syntaxhighlight>

Monta tu carpeta local del proyecto (../) dentro del contenedor, (/app). ¿Y por qué /app? Porque fue el espacio de trabajo que definimos en el Dockerfile. Como ves, la congruencia entre los Dockerfile y el docker-compose es importante.

Recarguemos de nuevo nustra configuración:

<syntaxhighlight lang="bash">
docker compose -f docker/docker-compose.yml up -d --build
</syntaxhighlight>

Ahora ya podemos trabajar con el código en host sin tener que reconstruir la imagen a cada cambio de línea.

== Cuidado con COPY y los bind mounts ==

Un '''bind mount''' (o “montaje de enlace”) es un tipo de volumen en el que Docker conecta directamente una carpeta de tu máquina (el host) con una carpeta dentro del contenedor.

Cuando usas un bind mount (por ejemplo ../:/app), Docker monta tu carpeta local sobre la ruta /app del contenedor.
Eso significa que todo lo que estaba en /app dentro de la imagen desaparece al arrancar el contenedor, porque queda “oculto” por el volumen.

Ahora bien, durante la construcción de la imagen usamos la directiva COPY. ¿Por qué? Porque necesitamos el archivo requirements.txt para instalar las dependencias de Python del proyecto. Pero... ¿realmente necesitamos copiar TODO? No, claro que no, podemos optar por copiar exclusivamente aquellos archivos que nos hagan falta durante '''LA CONSTRUCCIÓN''' de la imagen. El bind mount luego lo machacará.

'''Muy importante:''' los bind mounts, al igual que cualquier otro volumen, están disponibles '''DESPUÉS''' de la construcción de la imagen. Es un error común creer que porque definamos un bind mount en un docker-compose, esos archivos aparecen ya para el contenedor. '''Esto es una fuente inagotable de problemas en la práctica'''.

= Ejercicio 6: Distintas configuraciones de despliegue =

Volvamos al punto de partida:

<syntaxhighlight lang="bash">
rm -r docker
mv docker.bk docker
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
</syntaxhighlight>

Esta práctica ha sido engorrosa a propósito para quitar esa "magia" que existe cuando lanzas un comando simple de orquestación y todo se levanta y funciona perfectamente. Esa situación está muy bien para desarrollar, pero no para aprender.

Es importante que analices que existen distintos escenarios:

* Hay un docker-compose para desarrollo.
* Hay 3 docker-compose para producción.
* Hay 6 Dockerfiles distintos
* Hay 3 entrypoints distintos
* Hay una carpeta llamada letsencrypt y otra llamada nginx. Dentro de nginx hay dos archivos de configuración dependiendo de si estamos en dev o en prod.

== Autoevaluación ==

Estudia bien cada archivo. Tómate tu tiempo e intenta responder a estas preguntas:

* ¿Por qué en el docker-compose de dev NO se usa "ports" para enlazar con el host? (pista: nginx)
* ¿Qué es nginx y por qué es útil aquí?
* ¿Cuántos bind mounts usa el contenedor web en desarrollo? ¿Para qué sirve el bind mount del propio Docker?
* ¿Qué diferencia hay entre el entrypoint de desarrollo y el entrypoint de producción?
* ¿Por qué el servicio web en producción está montando todos esos bind mounts por separado? ¿No sería más sencillo hacer un volumen de todo el código?

== Ejercicio propuesto ==

* Levanta el entorno de Docker de desarrollo de uvlhub, siguendo la documentación oficial. Comprueba que puedes acceder a la app a través de localhost.
* Intenta correr los test de Selenium [https://docs.uvlhub.io/rosemary/testing/gui_tests#docker-environment-selenium-grid https://docs.uvlhub.io/rosemary/testing/gui_tests#docker-environment-selenium-grid]. Ten en cuenta que la forma de ejecutar y de visualizar los test de Selenium es distinta en un entorno Docker. Estudia bien la documentación, te hará falta para el desarrollo.

== Comentarios finales ==

=== Cuanto más se parezca el entorno de desarrollo al de producción, menos errores habrá ===

En desarrollo es tentador usar configuraciones cómodas: servidor de Flask con --reload, bind mounts, base de datos vacía, logs en consola, etc.
Pero cuanto más difiere ese entorno de producción, más probable es que algo falle al desplegar.

'''El código no falla por cambiar de servidor, sino porque los entornos se comportan distinto.'''

Ejemplos clásicos:

* En desarrollo usas SQLite, en producción MariaDB → aparecen errores de compatibilidad SQL.
* En desarrollo Flask sirve los archivos estáticos, en producción lo hace Nginx → las rutas cambian.
* En desarrollo ejecutas '''flask run''', en producción '''gunicorn''' → los hilos, workers o el reloader funcionan distinto.

Por eso, el objetivo ideal es que tu entorno de desarrollo (dev), de preproducción (staging) y de producción (prod) sean idénticos salvo por las credenciales.

Docker y docker-compose te permiten lograr eso: puedes usar la misma imagen base, cambiando solo el docker-compose (volúmenes, puertos, etc.).

=== Diferencia entre el servidor de Flask y Gunicorn ===

Flask trae incorporado un servidor de desarrollo.
Es muy útil para depurar porque:

* recarga automáticamente el código (--reload),
* muestra errores detallados en el navegador,
* solo ejecuta un proceso.

Sin embargo, no está pensado para producción:

* no maneja múltiples conexiones concurrentes,
* no tiene control de procesos ni balanceo de carga,
* no implementa estándares de rendimiento o seguridad (como WSGI robusto).

Ahí entra Gunicorn (Green Unicorn), que sí es un servidor WSGI de producción (Web Server Gateway Interface, estándar de comunicación entre aplicaciones web Python y servidores web):

* puede lanzar varios workers en paralelo,
* maneja múltiples peticiones concurrentes,
* se integra fácilmente con Nginx para servir contenido estático o HTTPS.

Prácticas - 25/26

2025-10-14T06:18:28Z

Jmorenol:

Archivo:EGC 2025-26 P4.pdf

2025-10-14T06:17:46Z

Jmorenol:

Tutorial Campo de entrenamiento 2526

2025-10-10T08:21:25Z

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

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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.

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

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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, 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> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

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.

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.

Y aunque en esta práctica nos hemos centrado en técnicas de automatización, recuerda que "automatizar pruebas sin diseño es como hacer una pizza sin base" :-)

¡Mucho ánimo!

Tutorial Campo de entrenamiento 2526

2025-10-10T08:16:45Z

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

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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.

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

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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, 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> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-10T08:15:02Z

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

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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, 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> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-10T08:13:30Z

Jmorenol: /* Pruebas unitarias con pytest */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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, 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> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:49:07Z

Jmorenol: /* Pruebas de interfaz con Selenium */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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, 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> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:46:58Z

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

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:28:46Z

Jmorenol: /* Algunas cuestiones que puedes investigar */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:26:56Z

Jmorenol: /* Ejecución de Locust */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se finalice la prueba:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:25:09Z

Jmorenol: /* Ejecución de Locust */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:24:48Z

Jmorenol: /* Ejecución de Locust */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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, 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>).

Luego, inicia la prueba.

En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:22:24Z

Jmorenol: /* Ejecución de Locust */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:21:24Z

Jmorenol: /* Pruebas de interfaz con Selenium */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T09:20:00Z

Jmorenol: /* Exportar el test a código Selenium WebDriver */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador (idéntica al estilo UVLHUB) ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T08:57:48Z

Jmorenol: /* Pruebas de interfaz con Selenium */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación a través de un navegador real.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

import os, time, pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.firefox.service import Service
from webdriver_manager.firefox import GeckoDriverManager

# === Configuración del navegador (idéntica al estilo UVLHUB) ===

def initialize_driver():
"""
Inicializa un driver de Firefox con configuración compatible con sistemas snap.
UVLHUB usa exactamente esta estructura.
"""
options = webdriver.FirefoxOptions()

# Directorio temporal alternativo (evita problemas con permisos en snap)
snap_tmp = os.path.expanduser("~/snap/firefox/common/tmp")
os.makedirs(snap_tmp, exist_ok=True)
os.environ["TMPDIR"] = snap_tmp

service = Service(GeckoDriverManager().install())
driver = webdriver.Firefox(service=service, options=options)
driver.set_window_size(1024, 768)
return driver

def close_driver(driver):
"""Cierra el navegador."""
driver.quit()

# === Tests de interfaz ===

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T08:47:22Z

Jmorenol: /* Ejecuta la aplicación */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella desde primero desde el navegador (<code>http://localhost:5000</code>), creando y visualizando las tareas usando el formulario web. Y luego también interactúa con la app mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T08:34:26Z

Jmorenol: /* Dependencias */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python3.12 -m venv .venv
source .venv/bin/activate
pip3.12 install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T08:30:45Z

Jmorenol: /* Dependencias */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
python -m venv .venv
source .venv/bin/activate
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:47:12Z

Jmorenol: /* Algunas cuestiones que puedes investigar */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:46:42Z

Jmorenol: /* Algunas cuestiones que puedes investigar */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:46:14Z

Jmorenol: /* Un ejemplo sencillo para ayudarte a arrancar */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar una primera prueba para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1. Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:45:04Z

Jmorenol: /* Un ejemplo sencillo para ayudarte a arrancar */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fíjate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía, comprobando el flujo completo desde el navegador del usuario. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1. Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:42:47Z

Jmorenol: /* Algunas cuestiones que puedes investigar */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

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

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1. Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. 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.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:35:45Z

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

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

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

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:28:55Z

Jmorenol: /* Pruebas de interfaz con Selenium */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

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

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:25:45Z

Jmorenol: /* Pruebas de carga con Locust */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

Ten en cuenta que en esta demostración usamos <code>print()</code> para poder ver la actividad de los usuarios simulados en tiempo real en la consola. En una prueba de carga a gran escala se evitarían los <code>print()</code> porque escribir en la consola consume recursos (I/O) y puede afectar ligeramente los resultados de rendimiento. Locust ya proporciona estadísticas detalladas en su interfaz web, que es la forma profesional de analizar los resultados, como vas a ver a continuación.

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:21:39Z

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

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real.

Por tanto, este archivo permite que las pruebas sean repetibles y aisladas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:20:27Z

Jmorenol: /* Código app/__init__.py: */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:18:47Z

Jmorenol: /* Código app/models.py: */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas. En una aplicación real esta lista global sería reemplazada por una base de datos (como ocurre en UVLHUB). Usar una variable global hace que los datos se pierdan cada vez que se reinicia el servidor y pueda no funcionar correctamente si múltiples usuarios acceden a la vez. Sin embargo, para aprender a escribir pruebas, es una simplificación muy útil

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:17:01Z

Jmorenol: /* Estructura del proyecto */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-07T07:16:33Z

Jmorenol: /* Código app/app.py: */

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/routes.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-06T20:08:03Z

Jmorenol:

= Automatización de pruebas software en una aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py.py
│
└── locustfile.py
</pre>

=== Desarrollo de la aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-06T17:44:45Z

Jmorenol: /* Pruebas de interfaz con Selenium */

= Automatización de Pruebas de Software en una Aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py.py
│
└── locustfile.py
</pre>

=== Desarrollo de la Aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
Equivalente a preparar datos iniciales en la base de datos en UVLHUB.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:

<syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de Carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-06T17:44:00Z

Jmorenol:

= Automatización de Pruebas de Software en una Aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py.py
│
└── locustfile.py
</pre>

=== Desarrollo de la Aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
Equivalente a preparar datos iniciales en la base de datos en UVLHUB.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
------- coverage: xxx% -------

Name Stmts Miss Cover
---------------- ------ ---- -----
app/__init__.py 1 0 100%
app/app.py 6 0 100%
app/models.py 9 0 100%
app/routes.py 26 2 92%
TOTAL 42 2 95%
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:
syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de Carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-06T17:42:29Z

Jmorenol:

= Automatización de Pruebas de Software en una Aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py.py
│
└── locustfile.py
</pre>

=== Desarrollo de la Aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
Equivalente a preparar datos iniciales en la base de datos en UVLHUB.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

{| class="wikitable" style="text-align:center;"
! Name !! Stmts !! Miss !! Cover
|-
| app/__init__.py || 1 || 0 || 100%
|-
| app/app.py || 6 || 0 || 100%
|-
| app/models.py || 9 || 0 || 100%
|-
| app/routes.py || 26 || 2 || 92%
|-
! TOTAL || 42 || 2 || 95%
|}

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:
syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de Carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!

Tutorial Campo de entrenamiento 2526

2025-10-06T17:41:44Z

Jmorenol:

= Automatización de Pruebas de Software en una Aplicación Flask =

== Parte 1: creamos pruebas para una aplicación sencilla ==

El objetivo de la primera parte de la práctica es que nos familiaricemos con diferentes tipos de pruebas usando una aplicación web desarrollada con Flask. Durante la práctica se implementarán los siguientes tipos de pruebas:

# '''Pruebas unitarias y de integración con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación y los endpoints de la API.
# '''Pruebas de cobertura''' para medir qué porcentaje de código está cubierto por las pruebas.
# '''Pruebas de interfaz con <code>Selenium</code>''' para simular el comportamiento de un usuario interactuando con la interfaz web.
# '''Pruebas de carga con <code>Locust</code>''' para evaluar el rendimiento de la aplicación bajo diferentes niveles de tráfico.

=== Dependencias ===

Instala las dependencias necesarias (¡pero recuerda hacerlo en un entorno virtual!):

<syntaxhighlight lang="bash">
pip install flask pytest pytest-cov selenium locust webdriver-manager
</syntaxhighlight>

=== Estructura del proyecto ===

<pre>
flask_testing_project/
│
├── app/
│ ├── __init__.py
│ ├── app.py
│ ├── models.py
│ ├── routes.py
│ └── templates/
│ └── tasks.html
│
├── tests/
│ ├── conftest.py
│ ├── test_unit.py
│ ├── test_integration.py
│ └── test_interface.py.py
│
└── locustfile.py
</pre>

=== Desarrollo de la Aplicación Flask ===

Vamos a crear una aplicación sencilla que gestione tareas. El usuario podrá ver las tareas en una interfaz web y agregar nuevas tareas utilizando un formulario. Además ofrece una API REST para la visualización y creación de tareas.

==== Código <code>app/__init__.py</code>: ====

<syntaxhighlight lang="python">
# app/__init__.py
# Indica que 'app' es un paquete Python y expone la factoría create_app.

from .app import create_app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Flask
from app.routes import bp as tasks_blueprint

def create_app():
app = Flask(__name__)
app.register_blueprint(tasks_blueprint)
return app
</syntaxhighlight>

==== Código <code>app/app.py</code>: ====

<syntaxhighlight lang="python">
from flask import Blueprint, jsonify, request, render_template, redirect, url_for
from app.models import get_all_tasks, create_task

bp = Blueprint('tasks', __name__)

@bp.route('/')
def task_list():
return render_template('tasks.html', tasks=get_all_tasks())

@bp.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': get_all_tasks()})

@bp.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
try:
create_task(title)
return redirect(url_for('tasks.task_list'))
except ValueError as e:
return str(e), 400

@bp.route('/tasks', methods=['POST'])
def create_task_api():
data = request.get_json()
title = data.get('title') if data else None
try:
task = create_task(title)
return jsonify(task), 201
except ValueError as e:
return jsonify({'error': str(e)}), 400

</syntaxhighlight>

==== Código <code>app/models.py</code>: ====

<syntaxhighlight lang="python">
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

def get_all_tasks():
"""Devuelve la lista de tareas."""
return tasks

def create_task(title):
"""Crea una nueva tarea con el título indicado."""
if not title:
raise ValueError("El título es necesario")
new_task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(new_task)
return new_task
</syntaxhighlight>

Como puedes ver, la aplicación no usa una base de datos ni un repositorio. Tan solo se usa una lista global y un par de funciones para leer y crear tareas.

==== Plantilla HTML ====

La plantilla <code>tasks.html</code> es la encargada de mostrar las tareas y proporcionar un formulario para agregar nuevas tareas.

Archivo <code>app/templates/tasks.html</code>:

<syntaxhighlight lang="html">
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Gestor de Tareas</title>
</head>
<body>
<h1>Gestor de Tareas</h1>

<form action="{{ url_for('tasks.add_task_html') }}" method="POST">
<input type="text" name="title" placeholder="Añadir nueva tarea">
<button type="submit">Añadir tarea</button>
</form>

<h2>Lista de Tareas:</h2>
<ul>
{% for task in tasks %}
<li>{{ task.title }} {% if task.done %}(completada){% endif %}</li>
{% endfor %}
</ul>
</body>
</html>
</syntaxhighlight>

=== Ejecuta la aplicación ===

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
export FLASK_APP=app.app:create_app
flask run
</syntaxhighlight>

Interactúa con ella creando y visualizando las tareas usando primero el formulario web y luego también mediante la API:

<syntaxhighlight lang="bash">
curl -X POST http://127.0.0.1:5000/tasks -H "Content-Type: application/json" \
-d '{"title": "Leer documentación de github actions"}'
curl http://127.0.0.1:5000/tasks
</syntaxhighlight>

=== Automatización de pruebas ===

==== Configuración del entorno de pruebas con <code>conftest.py</code> ====

El archivo <code>conftest.py</code> sirve para definir fixtures, que son funciones especiales que preparan el entorno antes de ejecutar los tests. En este proyecto, las fixtures garantizan que cada prueba empiece con datos limpios y una aplicación Flask lista para usarse:

# La fixture reset_task prepara los datos iniciales antes de cada test.
# La fixture test_client crea un cliente de pruebas que permite simular peticiones HTTP (como GET o POST) sin necesidad de arrancar el servidor real; así podemos probar las rutas de la aplicación de forma rápida y controlada.

En conjunto, este archivo hace que las pruebas sean repetibles, aisladas y automáticas.

<syntaxhighlight lang="python">
import sys, os, pytest
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from app.app import create_app
from app import models

@pytest.fixture
def test_client():
"""Crea la aplicación Flask en modo testing y devuelve su cliente HTTP."""
app = create_app()
app.testing = True
return app.test_client()

@pytest.fixture(autouse=True)
def reset_tasks():
"""
Fixture autouse (se ejecuta antes de cada test).
Restablece el estado inicial de la lista de tareas.
Equivalente a preparar datos iniciales en la base de datos en UVLHUB.
"""
models.tasks[:] = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

</syntaxhighlight>

==== Pruebas unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en comprobar el comportamiento de funciones individuales del modelo, sin depender de Flask, HTTP ni base de datos.

Archivo <code>tests/test_unit.py</code>:

<syntaxhighlight lang="python">
import pytest
from app import models

def test_get_all_tasks_returns_list_of_dicts():
"""get_all_tasks debe devolver una lista de tareas con formato correcto."""
result = models.get_all_tasks()
assert isinstance(result, list)
assert all(isinstance(t, dict) for t in result)
assert any(t['title'] == 'Comprar pan' for t in result)

def test_create_task_adds_new_item_and_increments_length():
"""create_task debe añadir una nueva tarea y aumentar la longitud de la lista."""
initial_len = len(models.tasks)
new_task = models.create_task("Aprender testing")
assert len(models.tasks) == initial_len + 1
assert new_task in models.tasks
assert new_task['title'] == "Aprender testing"

def test_create_task_increments_id_sequentially():
"""Los IDs de las nuevas tareas deben incrementarse de forma secuencial."""
last_id = models.tasks[-1]['id']
new_task = models.create_task("Nueva tarea")
assert new_task['id'] == last_id + 1

def test_create_task_raises_value_error_if_title_missing():
"""Si no se pasa un título, create_task debe lanzar ValueError."""
with pytest.raises(ValueError):
models.create_task("")

</syntaxhighlight>

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?

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

Estas pruebas verifican que la app Flask completa funcione correctamente,
comprobando las rutas, peticiones y respuestas HTTP.

Archivo <code>tests/test_integration.py</code>:

<syntaxhighlight lang="python">
def test_get_tasks_endpoint_returns_existing_tasks(test_client):
"""
GET /tasks debe devolver una lista JSON con las tareas iniciales.
"""
response = test_client.get('/tasks')
assert response.status_code == 200

data = response.get_json()
assert 'tasks' in data
assert any(t['title'] == 'Comprar pan' for t in data['tasks'])

def test_create_task_endpoint_returns_201_and_json(test_client):
"""
POST /tasks (API JSON) debe crear una nueva tarea y devolver status 201.
"""
response = test_client.post('/tasks', json={'title': 'Nueva tarea'})
assert response.status_code == 201

data = response.get_json()
assert data['title'] == 'Nueva tarea'
assert 'id' in data and isinstance(data['id'], int)

def test_create_task_without_title_returns_400_error(test_client):
"""
Si se intenta crear una tarea sin título, el servidor debe devolver error 400.
"""
response = test_client.post('/tasks', json={})
assert response.status_code == 400

data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_add_task_html_redirects_and_renders_new_task(test_client):
"""
POST /add_task (formulario HTML):
- debe aceptar datos enviados por formulario,
- redirigir a la lista de tareas,
- y mostrar la nueva tarea en el HTML.
"""
response = test_client.post(
'/add_task',
data={'title': 'Tarea desde HTML'},
follow_redirects=True # Sigue el redirect hasta la página final
)

# Comprobamos que la respuesta final es OK y contiene el título
assert response.status_code == 200
assert b'Tarea desde HTML' in response.data
assert b'Gestor de Tareas' in response.data

def test_create_then_retrieve_task_from_api(test_client):
"""
Flujo completo API:
1. Crear una tarea con POST /tasks
2. Recuperar todas las tareas con GET /tasks
3. Verificar que la nueva está presente
"""
test_client.post('/tasks', json={'title': 'Task persistente'})
response = test_client.get('/tasks')
data = response.get_json()

titles = [t['title'] for t in data['tasks']]
assert 'Task persistente' in titles

</syntaxhighlight>

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?

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

<syntaxhighlight lang="bash">
pytest -v
</syntaxhighlight>

Comprueba los resultados obtenidos. ¿Coinciden con lo que estabas esperando?

==== Pruebas de cobertura con <code>pytest-cov</code> ====

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?

La cobertura de código mide el porcentaje de código ejecutado cuando se lanzan las pruebas. Esto nos ayuda a identificar las áreas de la aplicación que no están siendo probadas adecuadamente.

===== Medir la cobertura de las pruebas con pytest-cov =====

<syntaxhighlight lang="bash">
pytest --cov=app tests/
</syntaxhighlight>

Este comando ejecutará todas las pruebas en la carpeta tests/ y generará un informe de cobertura que mostrará qué porcentaje del código fue ejecutado durante las pruebas.

Tras ejecutar la orden anterior deberías ver una salida del estilo de la siguiente:

<pre>
{| class="wikitable" style="text-align:center;"
! Name !! Stmts !! Miss !! Cover
|-
| app/__init__.py || 1 || 0 || 100%
|-
| app/app.py || 6 || 0 || 100%
|-
| app/models.py || 9 || 0 || 100%
|-
| app/routes.py || 26 || 2 || 92%
|-
! TOTAL || 42 || 2 || 95%
|}
</pre>

Donde 'Stmts' indica el número total de sentencias de cada archivo; 'Miss' indica el número de sentencias que no fueron ejecutadas por las pruebas; y 'Cover' el porcentaje de cobertura de las pruebas sobre cada archivo.

También se puede obtener un informe más detallado con:

<syntaxhighlight lang="bash">
pytest --cov=app --cov-report=html tests/
</syntaxhighlight>

Esta orden generará un informe HTML con detalles de qué líneas de código fueron ejecutadas durante las pruebas y cuáles no. El informe se generará en una carpeta llamada htmlcov/.

Para visualizar el informe, abre el archivo htmlcov/index.html en tu navegador:

<syntaxhighlight lang="bash">
xdg-open htmlcov/index.html
</syntaxhighlight>

Con este informe podrás ver función a función cuál es su cobertura, y te permitirá identificar nuevas pruebas que añadir para verificar estos casos no cubiertos.

==== Pruebas de interfaz con <code>Selenium</code> ====

Estas pruebas simulan la interacción de un usuario con la interfaz web de la aplicación.

Archivo <code>tests/test_interface.py</code>:
syntaxhighlight lang="python">

@pytest.fixture(scope="module")
def driver():
"""
Fixture que crea y cierra automáticamente el navegador antes y después de todos los tests del módulo.
"""
d = initialize_driver()
yield d
close_driver(d)

def test_add_task_via_web_form(driver):
"""
Flujo de prueba:
1. Abrir la aplicación en http://localhost:5000/
2. Escribir una nueva tarea en el formulario.
3. Pulsar el botón 'Añadir tarea'.
4. Comprobar que la nueva tarea aparece en la lista.
"""

# 1️ Navegar a la página principal
driver.get("http://localhost:5000/")
time.sleep(1) # pequeña espera para que la página cargue

# 2️ Buscar el campo de texto y escribir la tarea
input_box = driver.find_element(By.NAME, "title")
input_box.clear()
input_box.send_keys("Tarea Selenium")

# 3️ Enviar el formulario
submit_button = driver.find_element(By.CSS_SELECTOR, "button[type='submit']")
submit_button.click()
time.sleep(1) # espera breve tras el redireccionamiento

# 4️ Verificar que la nueva tarea aparece en la lista
page_source = driver.page_source
assert "Tarea Selenium" in page_source, "La nueva tarea no se muestra en la lista de tareas."
</syntaxhighlight>

¿Qué crees que va a ocurrir cuando ejecutemos esta prueba?

Pues vamos a lanzarla y comprobemos qué ocurre:

<syntaxhighlight lang="bash">
pytest -s tests/test_interface.py
</syntaxhighlight>

¿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>?

==== <code>Selenium IDE</code> ====

Y puede que estés pensando "sí, vale, las pruebas han funcionado como esperaba... pero si tuviera que escribir yo la prueba me costaría bastante trabajo".

Y es cierto, pero afortunadamente existe <code>Selenium IDE</code>, que es una herramienta fácil de usar que nos permite grabar interacciones en el navegador y convertirlas en scripts de prueba que pueden ser ejecutados automáticamente.

===== Instalar <code>Selenium IDE</code> =====

Selenium IDE está disponible como una extensión para los navegadores Firefox y Chrome. Una vez instalada la extensión, haz clic en el ícono de <code>Selenium IDE</code> en la barra de herramientas del navegador para abrirla.

===== Grabar una prueba con <code>Selenium IDE</code> =====

Iniciar una nueva grabación:

* Abre <code>Selenium IDE</code>.

* Selecciona <code>Create a new project</code> y dale un nombre a tu proyecto, por ejemplo, PruebasFlaskInterfaz.

* Introduce la URL de la aplicación Flask en ejecución.

Grabar la interacción:

* Haz clic en el botón de grabación en <code>Selenium IDE</code>.

* Acción 1: Abre la página principal de la aplicación Flask.

* Acción 2: En el formulario de tareas, escribe una nueva tarea, por ejemplo, "Tarea de Selenium IDE".

* Acción 3: Haz clic en el botón para añadir la tarea.

* Acción 4: Verifica que la nueva tarea aparece en la lista.

* Detén la grabación una vez que hayas completado estos pasos.

Guardar la prueba en <code>Selenium IDE</code>.

===== Ejecutar la prueba grabada =====

En <code>Selenium IDE</code>, selecciona la prueba grabada y haz clic en <code>Run current test</code>.
Observa cómo <code>Selenium IDE</code> reproduce automáticamente todas las acciones que realizaste durante la grabación (navegar, escribir en el formulario, etc.).

===== Exportar el test a código <code>Selenium WebDriver</code> =====

Exportar a Python:

* En <code>Selenium IDE</code>, selecciona el menú <code>Export</code> y elige <code>Python - pytest</code>.

* Selecciona la carpeta de pruebas y guárdalo como test_selenium_ide.py.

Ejecutar el test exportado:

Y ya puedes ejecutar el test exportado utilizando pytest:

<syntaxhighlight lang="bash">
$ pytest tests/test_selenium_ide.py
</syntaxhighlight>

Esto ejecutará el test generado por <code>Selenium IDE</code> en tu navegador usando <code>Selenium WebDriver</code>.

==== Pruebas de Carga con <code>Locust</code> ====

Locust simulará múltiples usuarios accediendo a la aplicación simultáneamente, realizando operaciones como cargar la lista de tareas y agregar nuevas tareas.

Archivo <code>locustfile.py</code>:

<syntaxhighlight lang="python">
from locust import HttpUser, task, between

class WebsiteTestUser(HttpUser):
wait_time = between(1, 5)

@task(2)
def load_tasks(self):
print("Cargando la lista de tareas...")
response = self.client.get("/tasks")
if response.status_code == 200:
print("Lista de tareas cargada correctamente.")
else:
print(f"Error al cargar la lista de tareas: {response.status_code}")

@task(1)
def create_task(self):
print("Creando una nueva tarea...")
response = self.client.post("/tasks", json={"title": "Tarea generada por Locust"})
if response.status_code == 201:
print("Tarea creada correctamente.")
else:
print(f"Error al crear la tarea: {response.status_code}")
</syntaxhighlight>

===== Ejecución de <code>Locust</code> =====

# Inicia la aplicación Flask si no estaba en ejecución:

<syntaxhighlight lang="bash">
flask run
</syntaxhighlight>

# Inicia Locust:

<syntaxhighlight lang="bash">
$ locust -f locustfile.py
</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.

# En la terminal verás mensajes como estos hasta que se haya lanzado el número de clientes indicado:

<pre>
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Cargando la lista de tareas...
Lista de tareas cargada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
Creando una nueva tarea...
Tarea creada correctamente.
[2024-10-07 17:35:02,798] hostname/INFO/locust.runners: All users spawned: {"WebsiteTestUser": 10} (10 total users)
</pre>

Y, además, en la interfaz de Locust en tu navegador (<code>http://localhost:8089</code>) puedes navegar por un informe interactivo con los resultados.

¿Cómo han ido las pruebas? ¿Ha aguantado el sistema esta carga?

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

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

Pero no te agobies por tener que aprender ahora algo nuevo como <code>rosemary</code>, ya que si echas un ojo al código del repositorio vas a ver que, en realidad, para lanzar las pruebas <code>rosemary</code> hace llamadas a <code>pytest</code>. Su uso es totalmente opcional, aunque es cierto nos hace la vida un poquito más fácil.

=== Un ejemplo sencillo para ayudarte a arrancar ===

Vamos a desarrollar pruebas unitarias para el módulo notepad que preparamos en la Práctica 1 del curso. Pero en lugar de hacerlo desde cero, vamos a ver si podemos inspirarnos con algunos de los tests ya creados en el repositorio. Por ejemplo, echa un ojo a los tests del módulo profile: <code>https://github.com/EGCETSII/uvlhub/blob/main/app/modules/profile/tests/test_unit.py</code>

Fijate bien en la función <code>test_edit_profile_page_get</code>.

Imagina que ahora quisiéramos crear un test para comprobar que el usuario de pruebas puede solicitar la lista de sus notepads, que inicialmente está vacía. ¿Podrías inspirarte en los tests del módulo profile para crear este otro? Sería muy similar, ¿verdad?

En el caso del notepad habría que hacer una petición get a <code>/notepad</code>, luego habría que comprobar que el código de respuesta es 200 y finalmente comprobar que en los datos de la respuesta aparece el texto "You have no notepads." Algo así, por ejemplo:

<syntaxhighlight lang="python">
def test_list_empty_notepad_get(test_client):
"""
Tests access to the empty notepad list via GET request.
"""
login_response = login(test_client, "user@example.com", "test1234")
assert login_response.status_code == 200, "Login was unsuccessful."

response = test_client.get("/notepad")
assert response.status_code == 200, "The notepad page could not be accessed."
assert b"You have no notepads." in response.data, "The expected content is not present on the page"

logout(test_client)
</syntaxhighlight>

=== Algunas cuestiones que puedes investigar ===

Partiendo de este ejemplo anterior, seguro que podrías ir diseñando las pruebas unitarias 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.

Por ejemplo, en UVLHUB se usan clases de servicio (como <code>NotepadService</code>, que creaste en la práctica 1). Estas clases encapsulan la lógica de negocio y se apoyan en un repositorio para acceder a la base de datos. En las pruebas unitarias 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 grandes, ya que facilita mantener las pruebas rápidas, independientes y centradas en una sola capa de la aplicación.

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!