Drorganvidez:

Tutorial-docker

2025-10-11T18:10:26Z

Drorganvidez: Página creada con «= Ejercicio 1: Empezamos desde cero — creando la estructura base de Docker = El objetivo es eliminar toda la configuración previa y crear desde cero la estructura de ca...»

= Ejercicio 1: Empezamos desde cero — creando la estructura base de Docker =

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

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

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

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

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.

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

== 10. 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.dev . </syntaxhighlight>

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

Innosoft - 25/26

2025-10-07T16:52:52Z

Drorganvidez:

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

En esta web encontraremos información sobre el desarrollo de las jornadas Innosoft durante el curso 25/26

== Propuestas de equipos de trabajo complementarios a los comités ==

* [[Llamada a la propuesta de equipos de trabajo - 25/26]]
* [[Evaluación de las propuestas - 25/26]]

En esta página se informa sobre el proceso de restablecimiento de contraseñas en Evidentia para el curso 2025/2026.

== Acceso a Evidentia ==

; Restablecimiento de contraseñas
El restablecimiento de contraseñas ya está funcionando correctamente en [https://evidentia.us.es Evidentia].
Cada alumn@ dispone de una contraseña aleatoria asignada por el sistema, por lo que es '''necesario restablecer la contraseña''' antes de acceder.

; Cómo hacerlo
Debes hacerlo usando tu correo institucional de alumn@, el mismo que aparece en '''Sevius'''.
Espera unos minutos a que llegue el correo de restablecimiento y revisa también la carpeta de '''spam'''.

; Acceso obligatorio
Aunque no participes activamente, '''tod@s l@s alumn@s deben poder entrar''', ya que las horas de asistencia también se contabilizan en este sistema.

; Soporte técnico
Si tienes algún problema, contacta con el grupo oficial de Telegram de soporte técnico: [https://t.me/evidentia_sat @evidentia_sat]

Archivo:EGC 2025-26 P2.pdf

2025-10-01T10:53:12Z

Drorganvidez: Drorganvidez subió una nueva versión de Archivo:EGC 2025-26 P2.pdf

Proyecto InnoSoft

2025-09-29T08:14:26Z

2024-10-15T07:51:32Z

Drorganvidez: /* Lanza la aplicación */

== 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 con <code>pytest</code>''' para comprobar la funcionalidad interna de la aplicación.
# '''Pruebas de cobertura''' para comprobar si nuestras pruebas tienen una buena cobertura de código.
# '''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.

==== Requisitos previos ====

Antes de comenzar, asegúrate de tener instalados los siguientes paquetes y herramientas:

* Python 3
* Flask
* <code>pytest</code> para pruebas unitarias.
* <code>pytest-cov</code> para la cobertura de código.
* <code>Selenium</code> para pruebas de interfaz.
* <code>Locust</code> para pruebas de carga.
* El navegador '''chromium''' y '''chromium-driver''' (para Selenium).

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

<syntaxhighlight lang="bash">
$ pip install flask pytest pytest-cov selenium locust
</syntaxhighlight>

===== Estructura del proyecto =====

<syntaxhighlight lang="bash">
flask_testing_project/
│
├── app.py # Archivo principal de la aplicación Flask
├── templates/ # Directorio que contiene la plantilla HTML
│ └── tasks.html # Plantilla para mostrar y agregar tareas
├── tests/
│ ├── test_app.py # Pruebas unitarias usando pytest
│ └── test_interfaz.py # Pruebas de interfaz con Selenium
└── locustfile.py # Archivo para pruebas de carga con Locust
</syntaxhighlight>

----

==== 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.py</code>: =====

<syntaxhighlight lang="python">
from flask import Flask, jsonify, request, render_template, redirect, url_for

app = Flask(__name__)

# Lista inicial de tareas (guardada en memoria)
tasks = [
{'id': 1, 'title': 'Comprar pan', 'done': False},
{'id': 2, 'title': 'Estudiar Python', 'done': False}
]

# Ruta para obtener la lista de tareas (versión HTML)
@app.route('/')
def task_list():
return render_template('tasks.html', tasks=tasks)

# Ruta para obtener la lista de tareas en JSON (API)
@app.route('/tasks', methods=['GET'])
def get_tasks():
return jsonify({'tasks': tasks})

# Ruta para crear una nueva tarea desde un formulario HTML
@app.route('/add_task', methods=['POST'])
def add_task_html():
title = request.form.get('title')
if not title:
return "El título es necesario", 400
task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': title,
'done': False
}
tasks.append(task)
return redirect(url_for('task_list'))

# Ruta para crear una nueva tarea (API JSON)
@app.route('/tasks', methods=['POST'])
def create_task():
if not request.json or 'title' not in request.json:
return jsonify({'error': 'El título es necesario'}), 400
task = {
'id': tasks[-1]['id'] + 1 if tasks else 1,
'title': request.json['title'],
'done': False
}
tasks.append(task)
return jsonify(task), 201

if __name__ == '__main__':
app.run(debug=True)
</syntaxhighlight>

Como puedes ver en el código, por tanto, se ofrecen dos formas para interactuar con las tareas:

# Una página HTML que muestra la lista de tareas y un formulario para añadir nuevas tareas.

# Una API REST que devuelve la lista de tareas en formato JSON y permite agregar nuevas tareas mediante solicitudes POST.

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

===== Lanza la aplicación =====

Veamos la aplicación en acción:

<syntaxhighlight lang="bash">
$ python3.12 app.py
</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>

==== Pruebas Unitarias con <code>pytest</code> ====

Las pruebas unitarias se centrarán en probar los endpoints de la API de manera independiente.

===== Archivo <code>tests/test_app.py</code>: =====

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

@pytest.fixture
def client():
with app.test_client() as client:
yield client

def test_get_tasks(client):
response = client.get('/tasks')
assert response.status_code == 200
assert 'Comprar pan' in response.get_data(as_text=True)

def test_create_task(client):
response = client.post('/tasks', json={'title': 'Aprender testing'})
assert response.status_code == 201
assert 'Aprender testing' in response.get_data(as_text=True)

def test_create_task_without_title(client):
response = client.post('/tasks', json={})
assert response.status_code == 400
data = response.get_json()
assert data['error'] == 'El título es necesario'

def test_task_list_updates(client):
response = client.post('/tasks', json={'title': 'Otra nueva tarea'})
assert response.status_code == 201

response = client.get('/tasks')
assert 'Otra nueva tarea' in response.get_data(as_text=True)
</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?

===== Ejecución de las pruebas: =====

<syntaxhighlight lang="bash">
$ pytest
</syntaxhighlight>

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

NOTA: Si recibes un error al lanzar pytest porque no se encuentra el módulo app, puedes intentarlo así (lo que añade el directorio actual (.) al PYTHONPATH):

<syntaxhighlight lang="bash">
$ PYTHONPATH=. pytest
</syntaxhighlight>

==== 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 en el archivo app.py 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.py | 26 | 8 | 69%
TOTAL | 26 | 8 | 69%
</pre>

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

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.

===== Un pasito previo para ver <code>Selenium</code> en acción =====

Antes de realizar las pruebas sobre nuestra aplicación vamos a hacer un pasito previo para comprobar que tenemos chromium y chromium-driver correctamente instalados y entender el tipo de cosas que podemos hacer con <code>Selenium</code>.

====== Archivo <code>tests/test_selenium.py</code> : ======

<syntaxhighlight lang="python">
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# Configurar Selenium para usar Chromium
options = webdriver.ChromeOptions()
# Quita '--headless' para ejecutar el navegador de manera visible
options.add_argument('--no-sandbox')
options.add_argument('--disable-dev-shm-usage')

# Iniciar el driver de Chromium
driver = webdriver.Chrome(options=options)

try:
# 1. Abrir Google
driver.get("https://www.google.com")

# 2. Esperar hasta que aparezca la ventana de cookies y hacer clic en "Rechazar todo"
reject_cookies_button = WebDriverWait(driver, 10).until(
EC.element_to_be_clickable((By.XPATH, "//button[contains(., 'Rechazar todo')]"))
)
reject_cookies_button.click()

# 3. Esperar hasta que el campo de búsqueda sea visible
search_box = WebDriverWait(driver, 10).until(
EC.visibility_of_element_located((By.NAME, "q"))
)

# 4. Escribir "Selenium" en la barra de búsqueda y enviar el formulario
search_box.send_keys("Selenium")
search_box.send_keys(Keys.RETURN)

# 5. Esperar a que el título cambie y contenga "Selenium"
WebDriverWait(driver, 10).until(EC.title_contains("Selenium"))
print("¡Selenium está funcionando correctamente con Chromium!")

except Exception as e:
print(f"Error: {e}")
driver.save_screenshot("error_screenshot.png")
print("Captura de pantalla guardada como 'error_screenshot.png'")

finally:
# Cerrar el navegador
driver.quit()
</syntaxhighlight>

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

Pues vamos a lanzarala y comprobemos qué ocurre:

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

¿Has visto cómo se ha lanzado el navegador y ha ido realizando los pasos indicados en el archivo <code>tests/test_selenium.py</code>? Pues ya tenemos todo listo para realizar las pruebas sobre nuestra aplicación.

===== Archivo <code>tests/test_interfaz.py</code>: =====

Ahora sí, vamos a crear las pruebas de la vista para nuestra aplicación.

<syntaxhighlight lang="python">
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
import pytest

@pytest.fixture
def driver():
print("Iniciando el navegador Chromium...")
driver = webdriver.Chrome()
yield driver
print("Cerrando el navegador Chromium...")
driver.quit()

def test_add_task(driver):
print("Abriendo la aplicación web en localhost:5000...")
driver.get("http://localhost:5000")

print("Verificando que el título de la página es correcto...")
assert "Gestor de Tareas" in driver.title

print("Buscando el campo de entrada de nueva tarea...")
input_field = driver.find_element(By.NAME, "title")

print("Escribiendo 'Tarea de Selenium' en el campo de entrada...")
input_field.send_keys("Tarea de Selenium")
input_field.send_keys(Keys.RETURN)

print("Verificando que 'Tarea de Selenium' aparece en la lista de tareas...")
assert "Tarea de Selenium" in driver.page_source
</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?

===== Ejecución de las pruebas de interfaz: =====

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

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

===== <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 mucho 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 - Selenium WebDriver</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">
$ python app.py
</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>

Partiendo de este ejemplo, ¿podrías ir diseñando las pruebas unitarias necesarias para comprobar todas las operaciones CRUD del módulo notepad?

¡Mucho ánimo!

Archivo:EGC 2024-25 P1.pdf

2024-09-26T11:12:07Z

Drorganvidez: Drorganvidez subió una nueva versión de Archivo:EGC 2024-25 P1.pdf

Práctica 1