Proyecto: MyPetCare - Infraestructura & QA Automation

Introducción

Más allá del desarrollo de la aplicación, este proyecto aborda el diseño de la infraestructura y la automatización de pruebas para un SaaS veterinario en producción. El objetivo es garantizar que cada cambio de código se valide automáticamente antes de llegar al usuario final, simulando el entorno real de despliegue de forma local y reproducible.

El Problema

La API de MyPetCare corre en Render y los 3 frontends (Veterinario, Admin, Clientes) en Netlify. Cada deploy a producción implicaba:

Desplegar directamente a Render/Netlify para probar cambios
Sin entorno local que replicara producción (API + 3 frontends + proxy)
Sin pruebas automatizadas del módulo de inventario (el más crítico)
Dependencia de la Raspberry Pi para pruebas en red local

Stack Tecnológico

Docker Compose Nginx (reverse proxy) Python 3.12 + gunicorn Playwright (E2E) Newman (API tests) GitHub Actions

Entorno Local con Docker Compose

Se diseñó un entorno local que replica exactamente la arquitectura de producción con un solo comando. El stack corre 2 contenedores:

API (Flask)

Python 3.12 + gunicorn. Se conecta a Supabase (externo). Healthcheck incluido.

Nginx (Proxy + Static)

Sirve los 3 frontends estáticos y ejecuta proxy inverso a /api/* → Flask.

Rutas de acceso:

localhost/vet/       → Panel Veterinario
localhost/admin/     → Panel Administración
localhost/clientes/  → Portal Clientes
localhost/api/       → API Flask (proxy)

Detalle técnico: El entrypoint de Nginx ejecuta inject-env.js para inyectar la configuración de cada frontend (API URL, Supabase credentials) y construye el portal de clientes con vite build. Todo configurable desde un archivo .env.

Suite de Pruebas Automatizadas

Se implementó una suite de 33 pruebas cubriendo las capas más críticas del sistema:

E2E Playwright — Panel Veterinario (19 tests)

• Login, logout, vista de mascotas
• Crear cliente, consulta con receta médica
• Flujo completo de citas
• CRUD de artículos: crear, editar, eliminar, SKU duplicado
• Entradas de stock: crear factura de compra, verificar existencias
• Flujo completo de inventario: crear → entrada → venta → verificar stock bajó
• ventas: carrito, pago en efectivo, recibo digital con QR

API Playwright API — Lógica FEFO y rechazos (3 tests)

• FEFO (First Expired, First Out): dos entradas con lotes de diferente caducidad, venta que cruza ambos. Verifica que el lote más antiguo se agota primero.
• Rechazo de venta: intento de vender más del stock disponible. Verifica HTTP 400 y que el stock no cambia.
• Rechazo de desperdicio: intento de registrar merma que excede el lote. Verifica integridad de datos.

Admin Playwright — Panel Admin (4 tests)

• Login, búsqueda de usuarios, subida de logo, smoke test

Clientes Playwright — Portal de Clientes (7 tests)

• Login, home, citas, directorio, perfil, registro

Validación de Lógica FEFO

El algoritmo FEFO (First Expired, First Out) es crítico para el control de inventario. La API descente stock priorizando el lote con fecha de caducidad más cercana. El test valida esto mediante un escenario real:

1. Crear artículo
2. Entrada 1: lote "ANTIGUO", caducidad 2026-12-31, cantidad 10
3. Entrada 2: lote "NUEVO",  caducidad 2027-06-30, cantidad 10
4. Venta de 15 unidades
5. Verificar: lote ANTIGUO → stock = 0 (agotado)
6. Verificar: lote NUEVO  → stock = 5 (restante)

Pipeline CI/CD (Próximos Pasos)

El entorno Docker está diseñado para integrarse en un pipeline automatizado con GitHub Actions:

git push → docker compose build → docker compose up
         → Playwright tests contra localhost
         → si pass → deploy a Render/Netlify

Esto permite validar automáticamente que ningún cambio rompa la API, los frontends o la lógica de inventario antes de llegar a producción.

Estructura del Repositorio

mpc_docker/
├── docker-compose.yml          ← Orquesta todo
├── .env.example                ← Variables configurables
├── docker/
│   ├── api/Dockerfile          ← Python 3.12 + gunicorn
│   └── nginx/
│       ├── Dockerfile          ← Nginx + Node.js 20
│       ├── default.conf        ← Reverse proxy + static
│       └── entrypoint.sh       ← Inyecta configs al iniciar
└── scripts/
    └── start.sh                ← Launcher interactivo

mpc_tests/
├── vet/tests/
│   ├── inventario.spec.js      ← Flujo completo (6 tests)
│   ├── articulos.spec.js       ← CRUD artículos (6 tests)
│   ├── entradas.spec.js        ← Entradas stock (4 tests)
│   └── ventas.spec.js          ← POS y recibo (5 tests)
├── api/tests/
│   └── fefo.spec.js            ← FEFO + rechazos (3 tests)
└── qa.config.js                ← Config por ambiente

Conclusión

Este proyecto demuestra la capacidad de diseñar entornos de prueba reproducibles que replican la arquitectura de producción. La combinación de Docker Compose para la infraestructura, Playwright para las pruebas E2E y la validación de lógica de negocio (FEFO) crea un sistema robusto que reduce riesgos en cada deploy y acelera el ciclo de desarrollo del producto.