Skip to main content

13. Estrategia de Pruebas y Aseguramiento de Calidad (QA)

(Última modificación: 2 de Junio de 2026)

Para un ERP de misión crítica como MDX-Cloud, donde un error en el algoritmo de inventarios (FEFO) o una falla en la sincronización Offline puede detener la operación de sucursales enteras, la estrategia de pruebas no es opcional. El ecosistema implementa una pirámide de pruebas obligatoria antes de autorizar el despliegue a producción.

13.1 Pruebas Unitarias de Reglas de Negocio (.NET)​

La capa de dominio de C# aloja el núcleo duro financiero y logístico de la empresa. Estos algoritmos deben testearse de forma aislada, sin tocar la base de datos real.

  • Herramientas: xUnit + Moq + FluentAssertions.
  • Algoritmos Críticos (Cobertura Obligatoria al 100%):
    1. Algoritmo de Extracción FEFO: Dado un pedido de 100 cajas y 3 lotes disponibles en el CEDIS, la prueba debe asegurar matemáticamente que el sistema deduce las cajas de los lotes más próximos a caducar.
    2. Algoritmo de Dispersión FIFO: Dado un abono de $50,000 MXN de un cliente, asegurar que el sistema liquida primero las facturas más antiguas antes de aplicar el remanente a las recientes.
    3. Matriz de Precios B2B: Asegurar que si un cliente tiene un descuento nivel "Oro" pero compra menos del mínimo requerido, se le aplique el precio "Base".

13.2 Pruebas de Integración y Concurrencia (PostgreSQL)​

El objetivo es validar que el motor de base de datos respete las políticas de integridad (Llaves foráneas) y que los candados transaccionales eviten las condiciones de carrera (Race Conditions).

  • Herramientas: Testcontainers (Contenedores Docker efímeros levantados exclusivamente para la prueba y destruidos al final).
  • Escenario Crítico (Doble Gasto): Simular dos hilos (Threads) ejecutándose en el mismo milisegundo intentando comprar las últimas 5 cajas de inventario. La prueba debe asegurar que la base de datos aborta y lanza una excepción (bloqueo pesimista o conflicto de versión xmin) en la segunda transacción, evitando inventario negativo.

13.3 Pruebas End-to-End (E2E) y Resiliencia Offline (Frontend)​

Este es el nivel más complejo del proyecto. Se debe garantizar que la interfaz gráfica en React reaccione correctamente ante la pérdida abrupta de la señal Wi-Fi en el almacén.

  • Herramientas: Playwright (por su capacidad de manipular el estado de la red y el Storage del navegador).
  • Flujo de Prueba Obligatorio (Offline Sync):
    1. El robot de prueba navega a la pantalla de "Captura de Pedido".
    2. Playwright intercepta la red y emula la desconexión total del internet (offline: true).
    3. El robot intenta agregar 3 productos al carrito y finaliza el pedido.
    4. La prueba valida que React guarde los datos en la tabla pending_pedidos de IndexedDB (Dexie.js) y no crashee mostrando la "Pantalla Blanca de la Muerte".
    5. Playwright restaura la conexión de red.
    6. La prueba espera 3 segundos y valida que el Service Worker vació la cola local y el pedido ya existe oficialmente en la grilla del sistema.

13.4 Pruebas de Estrés y Carga (Telemetría)​

Garantizar que el sistema en vivo (SignalR) no colapse cuando todas las sucursales abren a las 8:00 AM.

  • Herramientas: k6 (Herramienta de testing de carga escrita en Go).
  • Escenario de Simulación: Levantar 500 Usuarios Virtuales (VUs) simultáneos solicitando el catálogo de medicinas y abriendo túneles de WebSocket, monitoreando en Grafana (Stack PLG) que la memoria RAM del contenedor de Docker no supere el 80% y los tiempos de respuesta se mantengan por debajo de los 200 milisegundos.

13.5 Automatización Continua (CI/CD)​

(Última modificación: 2 de Junio de 2026)

Las pruebas descritas anteriormente no deben depender de la memoria humana. Se implementará una aduana de código automatizada (Robot Guardián) mediante pipelines de Integración Continua (ej. GitHub Actions o GitLab CI).

  1. Bloqueo en el Pull Request: Cuando un desarrollador intente fusionar nuevo código, la nube levantará contenedores efímeros y ejecutará automáticamente dotnet test (Unitarias e Integración) y las pruebas headless de Playwright.
  2. Tolerancia Cero (Zero Trust): Si un solo test de los algoritmos (ej. un fallo en el cálculo del FEFO o una falla de sincronización offline en React) da error, el pipeline se aborta (❌) y se prohíbe físicamente el pase a producción.
  3. Despliegue Automático (CD): Únicamente cuando el 100% de la batería de pruebas sea exitosa (✅), el pipeline autorizará la construcción de las imágenes Docker finales y su despliegue hacia el VPS y Cloudflare Pages.

13.6 Criterios de Aceptación (Definition of Done)​

(Última modificación: 2 de Junio de 2026)

Para que cualquier nueva funcionalidad (Feature), pantalla o módulo sea considerado formalmente como "Terminado" (Done) por el equipo de ingeniería y pueda ser liberado a producción, debe cumplir obligatoriamente con el siguiente checklist arquitectónico:

  1. Aislamiento Parcial y FKs de Seguridad: Se permite el uso de Llaves Foráneas (FKs) entre distintos esquemas lógicos en PostgreSQL única y exclusivamente como red de seguridad (fallback) para la integridad de datos. La lógica de C# (.NET) debe validar previamente las existencias en memoria mediante .Contracts y manejar las escrituras cruzadas mediante Transacciones Síncronas (IDbContextTransaction).
  2. Resiliencia Offline Verificada: Si la funcionalidad pertenece a un módulo operativo (WMS o Comercial), se probó apagando la red y comprobando que los datos se almacenan en IndexedDB (Prefijo pending_) sin bloquear al usuario.
  3. Cobertura de Pruebas (Luz Verde en CI): Todos los algoritmos matemáticos, logísticos o financieros involucrados tienen pruebas unitarias (xUnit) y pasaron exitosamente el pipeline de Integración Continua.
  4. Observabilidad: Los errores no controlados y transacciones clave están inyectando logs estructurados hacia Serilog (Stack PLG) para ser visualizados en Grafana.
  5. Seguridad (Tokens): El nuevo endpoint en .NET está protegido adecuadamente por el rol correspondiente y no expone el Access Token en las URLs ni en el Local Storage del navegador.

Cualquier Pull Request que no cumpla estrictamente con los 5 puntos anteriores será rechazado automáticamente en la revisión de código (Code Review).