TEST-01 Estrategia de verificación inicial

TEST-01 — Estrategia de verificación inicial

Objetivo de verificación

Confirmar que RF-01 se comporta según AC-01 y que cada US/tarea verifica sus criterios declarados.

Enfoque por capas

• Unitarias (dominio/aplicación): JUnit 6 + MockK. Se prueban invariantes y casos límite del hexágono sin framework ni base de datos.
• Integración (adaptadores): @SpringBootTest + Testcontainers postgres:17 para repositorios Exposed, migraciones Flyway, seguridad y webhooks.
• Contrato: validación del openapi.yaml y del cliente TypeScript generado en CI local; el contrato rompe el build si diverge del backend.
• E2E (señal de éxito): Playwright orquesta el flujo real: docker compose up → registro/login (US-03) → carrito (US-04) → checkout Mercado Pago sandbox, tarjeta o Yape (US-05) → webhook confirmado (BE-06) → orden PAID visible (US-06).
• Frontend: pruebas de componentes Angular con TestBed zoneless (await fixture.whenStable()), sin detectChanges() salvo wrappers.

Herramientas y versiones

Capa	Herramienta
Unit backend	JUnit 6 + MockK
Integración	Testcontainers (PostgreSQL 17)
Contrato	OpenAPI 3.1 + generador de cliente TS
E2E	Playwright
Frontend	Angular TestBed zoneless
Revisión de UI en curso	Playwright MCP (@playwright/mcp) contra la SPA local

Bucle del agente (Playwright MCP)

El objetivo de producto es que la vitrina se sienta como tienda (ARCH-07). Playwright MCP es la retroalimentación del agente mientras una FE de UI está abierta. La sesión no se versiona y no marca la tarea DONE.

Cada pasada mira la misma pantalla dos veces, en ~375px y ~1280px:

1. Snapshot de accesibilidad (browser_snapshot). Fuente para recorrer y para el estándar de uso: roles, nombres accesibles, encabezados, estado de controles, skip link y foco. Las acciones usan los refs de ese árbol.
2. Captura (browser_take_screenshot). Fuente para la composición: aire, jerarquía, CTA, desborde y restos de una piel anterior. No se pulsa por coordenadas; vision mode queda fuera de esta SPA.

Las dos tienen que cumplir el criterio de la tarea y ARCH-07. Una captura atractiva con un control sin nombre, o un árbol correcto con chrome desbordado, deja el criterio abierto. El fallo vuelve a la misma FE.

Hoy ese bucle cierra la piel de FE-16. FE-06 y FE-08 lo repiten cuando existan sus pantallas. FE-12 guarda el recorrido de compra como spec versionado y un comando local; ahí la captura es traza de un fallo, no una nota de diseño.

flowchart TD
  slice[Cambio de UI] --> snap[Snapshot de accesibilidad]
  slice --> shot[Captura en 375 y 1280]
  snap --> check{Cumple ARCH-07 y la FE}
  shot --> check
  check -->|abierto| slice
  check -->|cerrado| tests[Tests declarados en verde]
  tests --> done[DONE]

Cobertura mínima por tarea

• Cada tarea BE/FE declara en su documento qué pruebas la verifican.
• Ninguna tarea se marca DONE sin su evidencia de prueba declarada.

Exception handling tests

• Validación → 422 ProblemDetail con errors por campo.
• Constraint violation → 400 ProblemDetail.
• Conflicto de unicidad → 409 ProblemDetail.
• Fallo no controlado → 500 ProblemDetail sin stack trace.
• Sin token → 401; rol insuficiente → 403, ambos application/problem+json.

Evidencia esperada

Registro de verificación por criterio con fecha y responsable = persona desarrolladora. Una transcripción de Playwright MCP no sustituye ese registro.