yovi_es4a

La app dispone de una interfaz web para jugar al juego Y.

Se ofrecen varios modos de juego:

La aplicación incorpora un flujo de selección de variante antes de configurar la partida.

El tablero tiene tamaño variable, configurable por el usuario dentro de unos límites establecidos.

El usuario puede elegir quién empieza la partida:

El usuario podrá registrarse en la aplicación, o inciar sesión si ya tiene cuenta asociada.

El sistema almacena información detallada de cada partida:

Se proporciona un API externo documentado para la interacción con bots y sistemas externos.

El motor del juego está desacoplado de la interfaz web y se implementa como un servicio independiente en Rust.

El sistema incorpora monitorización y observabilidad mediante Prometheus y Grafana para analizar el comportamiento de los servicios.

Adecuación funcional: El motor debe garantizar el cumplimiento de reglas y la validación del estado de la partida, evitando acciones inválidas y guiando al usuario durante el juego.

Eficiencia de desempeño: Se busca respuesta ágil y sin “lag” en las operaciones principales, con un uso eficiente de recursos y soporte de concurrencia, apoyado en el motor en Rust y el despliegue en contenedores.

Compatibilidad / interoperabilidad: La comunicación entre subsistemas y con bots externos debe ser estable, clara y validada, basada en JSON con notación YEN y un API bien documentado.

Usabilidad: La web debe ser intuitiva y fácil de aprender, con una interfaz que indique turnos, opciones y restricciones, reduciendo errores del usuario.

Fiabilidad / disponibilidad: El sistema debe mantener estabilidad ante fallos habituales y ser observable/monitorizable para detectar caídas o degradaciones.

Seguridad: Se controlarán accesos (registro/login y API pública), validación de entradas y medidas de protección de credenciales (por ejemplo, cifrado/hasheado de contraseñas).

Mantenibilidad: El diseño modular por microservicios y la separación de responsabilidades deben permitir incorporar nuevas estrategias/reglas o cambios en el API minimizando el impacto en el resto del sistema.

Portabilidad: Al basarse en Docker, el sistema debe ser desplegable en distintos entornos con una instalación reproducible.

Jugador: Interactúa con el sistema a través de la interfaz web. Puede registrarse o iniciar sesión, configurar partidas, jugar en diferentes modos (local, contra bot o multijugador online), comunicarse con otros jugadores en tiempo real y consultar su historial/estadísticas.

Bot: Sistema externo que interactúa con YOVI mediante una API pública. Puede utilizar el método play enviando posiciones en notación YEN para obtener la siguiente jugada o acción, permitiendo automatizar partidas o realizar jugadas para competir contra el sistema.

Administrador: Responsable de desplegar, supervisar y mantener el sistema, asegurando su disponibilidad, correcto funcionamiento y monitorización.

YOVI: Sistema principal que ofrece la funcionalidad del juego Y. Ofrece una interfaz web para los usuarios y una API externa para integraciones con bots, gestionando la lógica de juego, las partidas, los usuarios y las estadísticas.

Web Browser (Jugador): Cliente desde el que el usuario accede a la aplicación web. Interactúa con el sistema mediante HTTPS cargando la SPA y realizando peticiones a la API.

Bot Externo: Cliente software que consume la API del sistema para interactuar con las partidas, utilizando endpoints REST (como /play) y enviando posiciones en formato JSON/YEN.

Servidor de despliegue (Docker): Entorno donde se ejecutan los distintos servicios del sistema, desplegados como contenedores independientes. Incluye:

La comunicación técnica principal del sistema se realiza a través del gateway, que actúa como punto central de acceso externo.

El navegador carga la aplicación frontend a través de este componente, y la webapp interactúa con los servicios backend (users y gamey) mediante REST/JSON.

En el caso del modo multijugador online, se establece además una comunicación en tiempo real mediante WebSockets entre el cliente y el servicio users, permitiendo la sincronización de partidas, gestión de salas y envío de mensajes entre jugadores.

Los bots externos acceden directamente al sistema a través del gateway, utilizando la API REST expuesta por gamey.

webapp (React + Vite + TypeScript): Interfaz web donde los usuarios juegan

users (Node.js + Express): Gestiona usuarios, autenticación y partidas

gamey (Rust): Motor del juego con las reglas y lógica del Juego Y

GitHub Issues para tareas y bugs

Kanban para seguimiento visual

Pull Requests con revisión obligatoria

Rama master protegida

Arc42 para la documentación del proyecto

Draw.io para realizar los diagramas

Wiki para las actas de las reuniones

Tablero (Board): Estructura triangular de tamaño variable (N×N casillas). Las posiciones se representan mediante coordenadas baricéntricas (x, y, z) donde x + y + z = N - 1, lo que facilita el cálculo de distancias a los lados.

Variante (Variant): Modalidad de juego que modifica las reglas base. El sistema soporta actualmente tres variantes jugables: la Clásica (reglas estándar del Juego Y), Tabu Y (ciertas celdas quedan bloqueadas) y Holey Y (hay celdas con agujeros en el tablero). La selección de variante se realiza antes de configurar la partida mediante el componente VariantSelect.

Partida (Game): Sesión de juego entre dos participantes (usuarios o bots). Contiene el estado del tablero, el turno actual, los jugadores, la variante activa y el historial de movimientos.

Movimiento (Move): Acción de colocar una pieza en una casilla libre. Se serializa en notación YEN para el intercambio entre servicios.

Notación YEN (Y Exchange Notation): Formato de serialización JSON inspirado en FEN (del ajedrez). Representa el estado completo de una partida (tablero, turno, jugadores, variante) para su almacenamiento o transmisión entre webapp, users y gamey.

Notación YGN (Y Game Notation): Formato de registro de la secuencia de movimientos de una partida completa, análogo al PGN del ajedrez.

Usuario: Persona registrada en el sistema con credenciales, historial de partidas y estadísticas.

Bot: Agente automático que juega partidas consumiendo el API público. Puede usar distintas estrategias de decisión.

Registro y autenticación: Los usuarios se registran y autentican mediante correo electrónico y contraseña. El sistema implementa una verificación en dos pasos (2FA por email) para confirmar la identidad del usuario antes de dar acceso a su cuenta.

Almacenamiento seguro de contraseñas: Las contraseñas nunca se almacenan en texto plano. Se guardan en MongoDB como hashes criptográficos (usando algoritmos como bcrypt), de forma que incluso un acceso no autorizado a la base de datos no exponga las credenciales reales.

Cifrado en tránsito (HTTPS): Toda la comunicación entre el cliente y el servidor pasa por el gateway, que gestiona la terminación TLS. En producción se emplea un certificado válido de Let’s Encrypt; en entorno local se genera un certificado autofirmado como fallback automático.

Validación de entradas: El servicio users valida todas las entradas recibidas (tanto de la webapp como de bots externos) para prevenir inyecciones y datos malformados.

Seguridad en WebSockets: Las conexiones Socket.io están protegidas y asociadas a la sesión del usuario, asegurando que solo los participantes de una sala puedan interactuar con su estado.

Red interna de Docker: MongoDB no expone puertos públicos; solo es accesible desde la red interna de contenedores (docker network), reduciendo la superficie de ataque.

Protocolo: HTTP/REST en todos los intercambios.

Formato de datos: JSON en todos los mensajes, incluyendo la representación del estado del juego en notación YEN.

Sincronía (REST): Las llamadas son síncronas (petición-respuesta) para operaciones de gestión (login, estadísticas, etc.).

Asincronía (WebSockets): Se utiliza Socket.io para la comunicación bidireccional en tiempo real durante las partidas multijugador. Esto permite la propagación instantánea de movimientos, mensajes de chat y cambios en el estado de la sala.

Documentación del API: El servicio users expone su API documentada con Swagger/OpenAPI, permitiendo que los desarrolladores de bots conozcan los endpoints disponibles, sus parámetros y los formatos de respuesta esperados.

Clásica: Reglas estándar del Juego Y. Base principal del sistema.

Tabu Y: Ciertas celdas están marcadas como tabú y no pueden utilizarse.

Holey Y: El tablero tiene agujeros (celdas inexistentes) que alteran la conectividad.

Fortune Dice: Variante que introduce un componente de azar mediante dados que pueden alterar el turno o el estado de las celdas.

Fortune Coin: Similar a Dice, pero con lanzamientos de moneda para decisiones binarias rápidas.

Pastel Y: Variante estética y funcional con una paleta de colores y reglas de puntuación suavizadas.

Master Y: Variante avanzada donde cada jugador coloca exactamente dos piezas por turno, aumentando la complejidad estratégica.

Bot aleatorio (random_bot): Elige una casilla válida aleatoria. Nivel de dificultad mínimo.

Bot MCTS (Monte Carlo Tree Search): Algoritmo probabilístico que simula miles de partidas aleatorias desde el estado actual para estimar estadísticamente la probabilidad de victoria de cada movimiento. Se implementa en múltiples niveles de dificultad (mcts_random, mcts_medio, mcts_dificil, mcts_demencial), diferenciados por el número de simulaciones y el tiempo de cómputo máximo. Se emplea paralelización mediante la librería rayon para optimizar el rendimiento en procesadores multinúcleo.

Recolección de métricas: Prometheus actúa como el recolector central, haciendo scraping periódico del endpoint /metrics de los diferentes servicios instrumentados. Registra métricas de rendimiento como tiempos de respuesta, número de peticiones, errores HTTP y uso de recursos.

Visualización: Grafana proporciona tableros de control (dashboards) para monitorizar en tiempo real el estado de los servicios, facilitando la detección temprana de fallos o degradaciones de rendimiento. Los dashboards se aprovisionan automáticamente como código (como volúmenes de configuración).

Trazabilidad de logs: Los servicios generan logs estructurados que permiten correlacionar eventos entre webapp, users y gamey para diagnosticar problemas en flujos completos.

Tests unitarios: Cada servicio tiene su suite de tests unitarios independiente (npm test para webapp y users, cargo test para gamey). Se verifica la lógica de negocio de forma aislada con mocks de dependencias.

Tests de integración: Se prueba la comunicación entre servicios para verificar que los contratos del API se cumplen correctamente.

Tests end-to-end (Playwright + Cucumber): La webapp incluye tests E2E con estilo BDD usando Playwright para la automatización del navegador y Cucumber (@cucumber/cucumber) para la definición de escenarios en formato Gherkin. Los tests se ejecutan con npm run test:e2e y están integrados en el pipeline de CI/CD.

Tests de rendimiento (Gatling): El módulo gatling/ contiene simulaciones de carga implementadas en Java DSL que cubren tres niveles: SmokeSimulation (verificación básica de disponibilidad), LoadSimulation (carga sostenida de usuarios concurrentes) y StressSimulation (sobrecarga para detectar el punto de ruptura del sistema). Estas pruebas se ejecutan contra el entorno desplegado.

Análisis estático (SonarCloud): Integrado en el pipeline de CI/CD, analiza cada pull request en busca de code smells, duplicidades, vulnerabilidades de seguridad y cobertura de tests. Se publica un Quality Gate público con el estado del proyecto.

Gestión de Tareas (Kanban): Se utiliza GitHub Projects con una metodología Kanban para visualizar el flujo de trabajo (To Do, In Progress, Done…​). Esto permite el seguimiento en tiempo real del estado de cada funcionalidad.

Seguimiento de Tareas (Issues): Cada nueva funcionalidad, error o mejora se documenta mediante Issues, que sirven como unidad básica de trabajo y permiten la trazabilidad de los requisitos hasta el código.

Flujo de Trabajo (Pull Requests): El código no se integra directamente en la rama principal (master, que está protegida). Se utilizan Pull Requests (PRs) para la revisión por parte de otros miembros del equipo, asegurando que el código cumpla con los estándares antes de ser fusionado.

Actas de reuniones (Wiki): Las reuniones semanales de equipo y las reuniones extraordinarias quedan registradas en la Wiki del repositorio de GitHub, garantizando trazabilidad de las decisiones tomadas.

Motor de Juego de Alto Rendimiento (Rust): El servicio gamey está desarrollado en Rust para garantizar la seguridad de memoria (sin garbage collector, sin carreras de datos) y un alto rendimiento en la evaluación del árbol de juego. Rust también ofrece versatilidad al poder ejecutarse tanto en modo servidor HTTP como en modo CLI para pruebas. La documentación del motor se genera automáticamente con cargo doc.

Backend de Gestión (Node.js/Express): El servicio users utiliza un entorno basado en eventos y JavaScript/TypeScript para gestionar la lógica de usuario de forma ágil y escalable. Node.js es especialmente apropiado para APIs REST con operaciones de I/O intensivas (acceso a MongoDB, llamadas a gamey).

Frontend Moderno (React + Vite + TypeScript): La interfaz de usuario (webapp) utiliza React para una gestión eficiente del estado de la UI, TypeScript para la seguridad de tipos en tiempo de compilación, y Vite como herramienta de construcción ultrarrápida en desarrollo.

Base de Datos Documental (MongoDB): La flexibilidad del esquema JSON/BSON facilita la evolución del modelo de datos sin migraciones complejas, y su integración nativa con el ecosistema JavaScript/TypeScript simplifica el desarrollo del servicio users.

Contenedorización (Docker + Docker Compose): Todos los servicios se empaquetan en imágenes Docker, garantizando la portabilidad y reproducibilidad del entorno en desarrollo, pruebas y producción.

Gestión de Avatares: Los usuarios pueden seleccionar y cambiar su imagen de perfil (avatar) entre una selección predefinida o mediante integración con servicios externos. El cambio se refleja instantáneamente en la interfaz y en las partidas multijugador.

Cambio de Nombre de Usuario: Se permite la modificación del nombre público (handle) del usuario, manteniendo la integridad del historial de partidas y estadísticas vinculadas a su cuenta única.

Privacidad y Seguridad: Los cambios de credenciales (contraseña) y datos sensibles requieren confirmación adicional para asegurar la cuenta.

Salas de Juego (Lobbies): Sistema de creación de salas privadas mediante códigos de invitación de 5 caracteres. Los usuarios pueden configurar la variante y el tamaño del tablero antes de que el oponente se una.

Chat Integrado: Durante las partidas multijugador, los jugadores disponen de un chat de texto para comunicarse. Los mensajes se envían de forma instantánea mediante WebSockets y se muestran en un panel lateral (MultiplayerChatDrawer).

Estado de Conexión: El sistema detecta y notifica la desconexión o el abandono de un rival, gestionando automáticamente la persistencia del resultado de la partida (derrota por abandono).

Estado: Aceptada.

Contexto: Se requiere un sistema de persistencia para almacenar los datos de los usuarios, partidas y estadísticas del juego que sea flexible y compatible con el ecosistema tecnológico actual.

Alternativas consideradas:

Justificación:

Consecuencias: Se espera mayor velocidad de desarrollo al no depender de esquemas rígidos. Como contrapartida, se renuncia a la consistencia transaccional fuerte entre colecciones, lo que es aceptable dado el dominio del problema.

Estado: Reemplazada (por ADR 3).

Contexto: Necesidad de una herramienta para crear los diagramas técnicos de la documentación arc42.

Alternativas consideradas:

Justificación:

Consecuencias: Permite la generación automática de diagramas visuales a partir de relaciones definidas por código, aunque carece de flexibilidad en la disposición visual manual, lo que provocó dificultades al representar arquitecturas complejas.

Estado: Aceptada.

Contexto: Tras evaluar el uso de PlantUML en los primeros diagramas, se identificó la necesidad de una representación más libre, esquemática y visual de los componentes, especialmente para los diagramas de despliegue y contexto.

Alternativas consideradas:

Justificación:

Consecuencias: Aunque requiere algo más de tiempo manual para la creación y no permite generación automática, resulta más cómoda, comunicativa y accesible para todo el equipo. Se usa conjuntamente con PlantUML para los diagramas de secuencia (vista de ejecución), donde la generación desde código sigue siendo ventajosa.

Estado: Aceptada (impuesta por los requisitos del proyecto).

Contexto: La lógica del juego Y, incluyendo la validación de movimientos, la detección de victoria y la implementación de bots, requiere un alto rendimiento, especialmente para el algoritmo MCTS que simula miles de partidas.

Alternativas consideradas:

Justificación:

Consecuencias: La curva de aprendizaje de Rust es significativa (gestión de lifetimes, ownership), lo que supuso un riesgo de retraso inicial. Se mitigó empezando con implementaciones simples y evolucionando gradualmente hacia algoritmos más complejos.

Estado: Aceptada.

Contexto: El sistema necesita integrar tecnologías heterogéneas (React, Node.js, Rust) y permitir el desarrollo en paralelo por parte de los distintos miembros del equipo.

Alternativas consideradas:

Justificación:

Consecuencias: Aumenta la complejidad operacional (hay que gestionar múltiples servicios, redes Docker, configuraciones de entorno). Se mitiga mediante docker-compose.yml que define toda la topología en un solo fichero y un pipeline de CI/CD completamente automatizado.

Estado: Aceptada.

Contexto: El bot del juego debe ofrecer al menos dos niveles de dificultad. Se necesita una estrategia de alto nivel que proporcione un oponente desafiante para usuarios avanzados.

Alternativas consideradas:

Justificación:

Consecuencias: El algoritmo MCTS es computacionalmente intensivo y puede causar tiempos de respuesta elevados si no se limita. Se implementa un límite de tiempo (timeout) para garantizar que el servicio gamey siempre responde dentro de un umbral aceptable, devolviendo el mejor movimiento encontrado hasta ese momento.

Estado: Aceptada.

Contexto: El proyecto requiere tests end-to-end que verifiquen los flujos completos del usuario (registro, login, selección de variante, partida) a través del navegador, tanto en local como en CI/CD.

Alternativas consideradas:

Justificación:

Consecuencias: Los tests E2E requieren que tanto la webapp como el servicio users estén arrancados. El script test:e2e:dev usa concurrently para levantar ambos servicios automáticamente durante el desarrollo. En CI, los navegadores de Playwright deben instalarse previamente con npx playwright install --with-deps.

Estado: Aceptada.

Contexto: El proyecto requiere pruebas de carga y rendimiento para validar que el sistema se comporta correctamente bajo diferentes niveles de concurrencia, en línea con los requisitos de calidad de la asignatura.

Alternativas consideradas:

Justificación:

Consecuencias: Las pruebas de rendimiento se ejecutan contra el entorno desplegado (producción o staging), por lo que no se incluyen en el pipeline de cada PR para evitar interferencias. Se ejecutan manualmente o en releases planificadas.

Estado: Aceptada.

Contexto: El sistema debe servirse por HTTPS en producción para garantizar la seguridad de las comunicaciones. Se necesita una solución que funcione tanto en producción (dominio público) como en local (sin dominio real).

Alternativas consideradas:

Justificación:

Consecuencias: El puerto 80 debe estar libre en el momento del arranque del gateway para que certbot pueda completar el challenge de Let’s Encrypt. En entorno local, el navegador mostrará una advertencia de seguridad por el certificado autofirmado, lo que es aceptable para desarrollo.

Estado: Aceptada.

Contexto: El modo multijugador requiere una comunicación bidireccional de baja latencia para sincronizar los movimientos entre jugadores, gestionar el chat y actualizar el estado de la sala.

Alternativas consideradas:

Justificación:

Consecuencias: Introduce una dependencia adicional en el stack de backend y frontend, y requiere configurar el gateway para permitir el upgrade de protocolo HTTP a WebSockets.

Estado: Aceptada.

Contexto: En el modo multijugador, es crítico asegurar que los resultados de las partidas se guarden correctamente incluso si un jugador abandona o se desconecta inesperadamente.

Alternativas consideradas:

Justificación:

Consecuencias: El servidor users debe mantener un estado en memoria de las salas activas para poder procesar las desconexiones correctamente.

Estado: Aceptada.

Contexto: Se desea mejorar la retención de usuarios y la experiencia social permitiendo que cada jugador se identifique visualmente en la plataforma.

Alternativas consideradas:

Justificación:

Consecuencias: Requiere ampliar el modelo de usuario en MongoDB y los endpoints del API para gestionar la actualización y recuperación de las preferencias estéticas.

Completitud funcional: Se cubren los requisitos de jugabilidad implementando las acciones propias del juego Y y sus distintas variantes (como Tabu Y y Holey Y), competición contra diferentes niveles de dificultad de bot (Random, Greedy, MCTS), contra otro usuario en local y en online junto con chat. SC8 SC12

Corrección funcional: Se contemplan las reglas de juego desde el motor, garantizando una validación precisa del estado de la partida en cada momento. Se guía al usuario a seguir correctamente el desarrollo de partida. SC1

Comportamiento en el tiempo: Se garantiza un tiempo de respuesta óptimo al utilizarse Rust en el motor del juego. Además de la implementación de una estrategia cuidada del algoritmo de respuesta.

Utilización de recursos: El despliegue mediante contenedores Docker permite una gestión eficiente de la memoria y la CPU para los tres subsistemas (webapp, users, gamey). SC4

Capacidad: Se limitan los tamaños de tablero dentro de un rango para que siga siendo jugable dentro de la configuración que el usuario escoja.

Facilidad para interoperar: El intercambio de información entre subsistemas se realiza estrictamente mediante mensajes JSON siguiendo la notación YEN, asegurando que el API sea compatible tanto con la WebApp como con bots externos.

Coexistencia: Se implementan test E2E que garantizan el flujo correcto de funcionamiento entre todos los microservicios de la aplicación.

Inteligibilidad: Dispone de una interfaz clara e intuitiva diseñada con React para facilitar su uso a todo tipo de usuario. Se busca tener un aspecto actualizado.

Capacidad de aprendizaje: El juego sigue reglas sencillas con facilidad de aprendizaje. La dificultad está presente en aprender qué estrategia seguir.

Operabilidad: La propia interfaz te guía durante el juego mostrándote de quién es el turno, las casillas disponibles y opciones disponibles. SC2

Protección contra errores de usuario: Aquellas acciones que desencadenarían algún fallo, como por ejemplo jugar fuera de tu propio turno, están deshabilitadas, previendo una mala práctica del juego. Además, se realizan validaciones de seguridad en los datos de entrada (ej. username).

Participación del usuario: Se dispone de una interfaz interactiva con distintas funciones para que el usuario, además de jugar al juego, pueda registrarse, personalizar su perfil (como cambiar su avatar o nombre de usuario), comparar su nivel en un ranking global y disponer de sus estadísticas personales de manera muy visual y gráfica. SC13 SC14 SC15

Accesibilidad: Cualquier persona de habla hispana puede acceder al juego. No tiene soporte de idiomas. SC3 El uso de un DNS permite que los usuarios accedan a la aplicación mediante un nombre legible (yovies4a.duckdns.org) en lugar de una dirección IP técnica y difícil de recordar. SC7

Asistencia al usuario: Dispone de una ayuda para entender qué hace cada componente en cada caso, además de tooltips y mensajes descriptivos.

Autodescripción: Se busca dejar lo más claro posible el uso de cada herramienta ya sea con un texto descriptivo en botones o dibujos que indiquen claramente su finalidad.

Madurez: A lo largo de todo el proyecto se utiliza SonarCloud para mantener cierta calidad de código. Se han realizado pruebas unitarias y de integración para garantizar la estabilidad del sistema.

Disponibilidad: Se utilizan las herramientas Prometheus y Grafana para monitorizar el estado de los microservicios y detectar posibles caídas o problemas de rendimiento.

Confidencialidad: Se implementa un sistema de registro apoyado por una base de datos para almacenar a los usuarios, los cuales se autenticarán para acceder a sus cuentas mediante autenticación en dos pasos con un botón que se manda por correo.

Integridad: Se implementa un grado más de seguiridad cifrando las contraseñas de los usuarios mediante función hash, así nosotros tampoco contamos explicitamente con estas. SC5

No repudio: Se guarda en la base de datos la interacción del usuario con la aplicación junto con una serie de datos estadísticos, por lo que el correo asociado con la cuenta guarda un registro de actividad.

Modularidad: El proyecto está dividido en tres microservicios (gamey, users y webapp). A su vez, en cada uno se sigue una estructura con las resposabilidades bien definidas y una clara separación de capas. Así se garantiza que un mínimo cambio no provoca un efecto de cascada. SC6 SC9

Extensibilidad: Se ha diseñado una API de Bots que permite incorporar nuevas estrategias de inteligencia artificial (ej. Random, Greedy, MCTS Completo) de manera modular sin afectar al núcleo del motor del juego. SC11

Adaptabilidad: Al estar basado en Docker, el proyecto es independiente del sistema operativo, lo que facilita su despliegue en diferentes entornos.

Instalabilidad: Mediante scripts de npm y comandos de Cargo, se levanta el entorno al completo rápidamente, con todos los componentes ya configurados.

Tecnología: Se utiliza Vitest como framework de ejecución de pruebas debido a su velocidad e integración nativa con Vite.

Alcance:

Backend (Users): Pruebas de los modelos de Mongoose, servicios de lógica de negocio y controladores de API utilizando supertest.

Frontend (WebApp): Pruebas de componentes React utilizando React Testing Library, hooks personalizados y utilidades de lógica de juego.

Motor de Juego (Gamey): Pruebas unitarias de la lógica del motor (movimientos, reglas, estados) y pruebas de integración para el servidor de bots.

Ejecución:

Para ejecutar las pruebas en local: npm run test (en webapp y users) y cargo test (en el motor de juego).

Integración continua: Se ejecutan automáticamente en cada Push o Pull Request a través de GitHub Actions.

Pruebas de Propiedades (Property-based Testing): Se utiliza la librería proptest para generar casos de prueba aleatorios pero controlados, asegurando que las invariantes del motor de juego se mantienen bajo cualquier circunstancia.

Benchmarks: Se utiliza Criterion para realizar análisis de rendimiento y detectar regresiones en la velocidad de ejecución de los algoritmos de juego.

Tecnología: Se utiliza Cucumber.js para la definición de escenarios en lenguaje natural (Gherkin) y Playwright para la automatización del navegador.

Metodología: Desarrollo guiado por comportamiento (BDD). Los escenarios se definen en archivos .feature que describen el comportamiento esperado sin entrar en detalles técnicos.

Escenarios Clave:

Flujo de Usuario: Registro exitoso, validación de email, inicio de sesión y gestión de perfil.

Jugabilidad: Inicio de partidas, turnos correctos, detección de victoria/empate y persistencia de resultados.

Social: Funcionamiento del chat, ranking global e historial de partidas.

Herramientas: Se utiliza el motor de cobertura v8 integrado en Vitest.

Estado Actual:

WebApp: Se mantiene una cobertura superior al 85%, con especial atención a las vistas críticas y servicios de socket.

Users Microservice: La cobertura supera el 87%, garantizando la seguridad en la gestión de cuentas y persistencia.

Motor de Juego (Rust): Gracias al tipado fuerte y las pruebas exhaustivas (unitarias y de propiedades), el motor mantiene una alta fiabilidad, con métricas de cobertura integradas en el análisis global.

Calidad Continua: Los resultados se exportan a SonarCloud, donde se monitorizan métricas de complejidad ciclomática, duplicación de código y "code smells".

Smoke Test (SmokeSimulation): prueba de humo orientada a validar rápidamente que las rutas principales de la aplicación funcionan correctamente. Se ejecuta con una carga mínima y recorre operaciones clave como obtención de metadatos, consulta de ranking, perfil, estadísticas, partidas contra bot, partidas multijugador y guardado de histórico.

Load Test (LoadSimulation): prueba de carga que simula un entorno de uso más realista. Incrementa progresivamente el número de usuarios concurrentes hasta alcanzar un estado estable, permitiendo observar el comportamiento del sistema bajo una carga nominal. La simulación combina varios perfiles de uso: visitantes, jugadores contra bot, partidas multijugador y ráfagas de peticiones externas.

Stress Test (StressSimulation): prueba de estrés diseñada para someter el sistema a una carga elevada y comprobar si mantiene la disponibilidad, los tiempos de respuesta y la tasa de éxito dentro de unos límites aceptables. Esta simulación genera una carga agresiva contra el API Gateway, incluyendo movimientos continuos, bots internos, visitantes pesados y ráfagas de peticiones. El objetivo es detectar el punto de degradación y analizar cómo responde la arquitectura ante condiciones extremas.