Saltar a contenido

ADR-017 — Suite E2E visual/funcional con Playwright contra el jar empaquetado

  • Status: accepted (operador aprobó la dependencia nueva el 2026-08-21)
  • Context: El sistema reparte 100 premios con acta legal. Los 117 tests de backend y 71 de frontend prueban invariantes y componentes, pero nada prueba el flujo completo en un navegador real sobre la topología de producción (un jar que sirve API + landing + gestor). La landing se usa en un 99 % desde celulares baratos en el salón.
  • Alternatives:
  • Pruebas manuales con checklist (SMOKE-M6): necesarias para lo físico (cámara, ticket real) pero no repetibles ni escalables a 100+ casos.
  • Agente con navegador (Claude en Chrome): útil para explorar; no es determinista ni corre en CI.
  • Playwright (elegida): emulación de dispositivos reales (Chromium Android, WebKit como motor de Safari iOS), screenshots con baseline, throttling de red, paralelismo, reportes JUnit que el ledger ingiere.
  • Decision: Carpeta e2e/ propia (@playwright/test, Chromium + WebKit). El sistema bajo prueba es el jar arrancado por el runner con perfil e2e: DB SistemaPremios_e2e (clean+migrate por corrida), rate limit desactivado salvo un test aislado, clave demo por seed. Los tests fabrican sus tokens (helper TS espejo de QrToken, validado contra el token de referencia) y eligen la fecha de emisión que necesitan: el bucketing es por emisión, no hace falta manipular el reloj. Proyectos: android-chico (360×740, baselines principales), iphone-webkit (390×844), android-grande, escritorio (humo); gestor en escritorio + tablet. Plan y matriz completa: docs/E2E-PLAN.md.
  • Consequences: ~130 tests, 8-12 min con 4 workers. Baselines visuales atados a la máquina que los generó (regenerar en CI Linux). Nunca corre contra SistemaPremios ni _test. El escaneo PDF417 queda fuera (cámara física → SMOKE-M6). Los reportes entran al ledger como repo e2e (dimensión integration).

Implementation Plan

  • e2e/ con playwright.config.ts (webServer = java -jar con env e2e), helpers/token.ts, helpers/api.ts (seed vía API del gestor), fixtures/, specs por grupo A/B/C del plan.
  • Backend: application-e2e.properties (DB e2e, flyway clean habilitado, rate limit off).
  • uscha.config.json: repo e2e tipo node para el ledger.

Verification

  • [ ] npx playwright test verde local con los 4 proyectos; JUnit en e2e/reports/junit.xml.
  • [ ] Journey maestro: otorgados + no otorgados + stock = 100 al final de la campaña.
  • [ ] Ninguna conexión a DBs que no sean SistemaPremios_e2e.