## Cómo probamos el sitio

Este sitio lo usa una comunidad real: gente que se inscribe a eventos con cupo, sube fotos, deja su contraseña. Por eso lo tratamos como software serio: 120 archivos de tests automatizados con 844 casos que corren antes de cada push, validación en el cliente y en el servidor, tipos estrictos y 121 casos manuales escritos para lo que todavía se prueba a mano. Todo está acá abajo, con el link al código.

1. 01 pre-commit$ pnpm exec lint-stagedHusky corre lint-staged, que formatea con Prettier solo los archivos que cambiaste (js, ts, tsx, json, css, md). Nadie commitea código sin formatear.
2. 02 pre-push$ pnpm lint && pnpm format:check && pnpm test && pnpm buildESLint, el chequeo de formato, toda la suite de Jest y el build de producción de Next.js (que incluye el chequeo de tipos de TypeScript). Si algo falla, el push no sale.
3. 03 pull request$ pnpm screenshot /ruta && pnpm screenshot:publishCada cambio entra por una PR hacia testing que revisa otra persona. Si toca la UI, lleva capturas de las rutas afectadas tomadas con Playwright (Chromium headless) y publicadas en la branch huérfana pr-screenshots.
4. 04 deploy$ pnpm prisma migrate deploy && kamal deployEl push a main dispara GitHub Actions: instala con el lockfile congelado (--frozen-lockfile), aplica las migraciones pendientes y despliega con Kamal, que solo pasa el tráfico a la versión nueva cuando responde el health check de /up.
5. 05 producción$ /monitoreo · /analiticasLos errores del servidor y del cliente quedan en ErrorLog (con el usuario y la ruta) y se revisan y marcan como resueltos desde /monitoreo; los logs de la app y las visitas también se guardan para investigar.

## La suite automatizada por capa

La mayoría de los tests están en la base de la pirámide: rápidos, sin red ni base de datos, y la suite completa tarda segundos. Cada caso automatizado del repositorio de abajo es uno de estos tests.

## Herramientas

Jest 30

El runner de toda la suite automatizada, configurado con next/jest (que usa el compilador SWC de Next.js para TypeScript). Corre en entorno node y solo busca src/**/*.test.ts. jest.config.mjs ↗

jest-mock-extended

jest.setup.ts reemplaza el cliente de Prisma por un mockDeep tipado y lo resetea antes de cada test: las server actions se prueban sin base de datos y TypeScript avisa si un mock no coincide con el modelo. jest.setup.ts ↗

Helpers de test

src/test trae mockCookies(), mockHeaders() y prismaMock para armar cada escenario (anónimo, logueado, admin) en una línea. jest.setup.ts además simula redirect() de Next.js lanzando NEXT_REDIRECT:/ruta, igual que en producción. src/test/cookies.ts ↗

Playwright

Configurado para Chromium, Firefox y WebKit (playwright.config.ts). Hoy se usa para tomar las capturas de las PRs (scripts/pr-screenshots.mjs); la suite E2E de tests/ es todavía un smoke test inicial. scripts/pr-screenshots.mjs ↗

TypeScript strict

strict y strictNullChecks activados en tsconfig.json: null, undefined y los tipos de Prisma se chequean en todo el código. El build falla con cualquier error de tipos. tsconfig.json ↗

Zod

Schemas en src/schemas que validan lo mismo en el formulario (react-hook-form + zodResolver) y en la server action, con los mensajes de error en español. El cliente nunca es la única validación. src/schemas/event-schema.ts ↗

Prisma

Cliente tipado generado desde el schema, restricciones únicas compuestas en la base (no se puede inscribir dos veces a la misma persona) y migraciones SQL versionadas que el deploy aplica antes de levantar la versión nueva. prisma/schema.prisma ↗

ESLint 9 + Prettier

Flat config con eslint-config-next/core-web-vitals (reglas de React, hooks, Next.js y parte de jsx-a11y) y eslint-config-prettier; Prettier 3 con el plugin que ordena las clases de Tailwind. eslint.config.mjs ↗

Husky + lint-staged

Los hooks de git que hacen de CI local: nada llega al repo sin pasar los checks. .husky/pre-push ↗

Rate limiting

Ventana deslizante por usuario (o por IP si es anónimo) para cada formulario: login, registro, códigos, contenido, comentarios, inscripciones, uploads, descargas. Los admins no tienen límite y el error viaja en RateLimitError.digest porque producción oculta los mensajes. src/lib/rate-limit.ts ↗

Bases aisladas por worktree

Cada worktree de git tiene su propia base de Postgres (scripts/setup-worktree-db.sh) y su URL con portless, así se prueban varias branches en paralelo sin pisarse datos ni puertos. scripts/setup-worktree-db.sh ↗

MailHog

En desarrollo los emails (códigos de verificación, recuperación de clave, avisos) no salen a internet: docker-compose levanta MailHog y se leen en localhost:18025. docker-compose.yml ↗

## Técnicas

Tests colocalizados

Cada test vive al lado del código que prueba (create-event.ts → create-event.test.ts). Si movés o borrás el módulo, el test va con él.

Test doubles

Prisma, cookies(), headers(), revalidatePath, S3, el envío de emails y fetch se reemplazan por mocks: los tests son rápidos, deterministas y no tocan servicios reales.

Matriz de permisos

Casi toda server action se prueba primero por lo que tiene que rechazar: sin cookie de sesión, con sesión vencida o inexistente, usuario que no es el autor, que no es organizador, que no es admin. Recién después el camino feliz. src/actions/advises/delete-advise.test.ts ↗

Testing negativo y de bordes

Particiones de equivalencia y valores límite sobre los schemas: contenido vacío, un carácter de más, fechas en el pasado, cupo lleno exacto, códigos vencidos o ya usados. src/schemas/event-schema.test.ts ↗

Tests parametrizados

it.each recorre tablas de casos (direcciones IP privadas, redirecciones peligrosas, cada track de entrevistas) con un solo cuerpo de test. src/lib/safe-redirect.test.ts ↗

Tiempo controlado

jest.useFakeTimers y setSystemTime congelan el reloj para probar ventanas del rate limit y qué eventos son "próximos" sin depender de cuándo corre el test. src/lib/rate-limit.test.ts ↗

Tests de seguridad

SSRF al validar URLs embebibles (IPs privadas, metadata de la nube, cada salto de redirección), open redirect después del login, URLs firmadas de CloudFront para la galería, costo de bcrypt y re-hash de contraseñas viejas. src/lib/embeddable.test.ts ↗

Binarios reales

El procesamiento de fotos se prueba con imágenes generadas con sharp en el momento: que achique, que nunca agrande, que respete la rotación EXIF y que salga en webp. src/lib/photo-processing.test.ts ↗

Integridad de contenido

El contenido estático versionado también se testea: cada guía de entrevistas tiene secciones con ids únicos y contenido, cada ejercicio de live coding está completo. src/app/(platform)/entrevistas/guias/guides/guides.test.ts ↗

Revisión visual

Las capturas de cada ruta afectada van en la PR para que la revisión no dependa de levantar el proyecto.

Testing manual exploratorio

Lo que no está automatizado (flujos en el navegador, PWA, PCN OS, responsive, accesibilidad) se prueba a mano siguiendo los casos de este repositorio antes de mergear a main.

## Lo que falta (planeado, todavía no está)

Ser honestos con lo que no hay también es parte de la calidad. Esto no existe todavía en el repo; es lo próximo que sumaríamos. Si te interesa, es un buen lugar para contribuir.

[ ] CI en las PRs

Hoy los checks corren en los hooks de cada máquina; un workflow de GitHub Actions que repita lint, tipos, tests y build en cada PR evitaría depender de que nadie use --no-verify.

[ ] Suite E2E real

Convertir los casos manuales de prioridad alta (login, registro, inscripción a eventos, subir fotos) en tests de Playwright contra una base sembrada.

[ ] Accesibilidad automatizada

Sumar @axe-core/playwright a la suite E2E para detectar contraste, labels y roles faltantes en cada ruta.

[ ] Cobertura

jest --coverage con un umbral mínimo en src/lib y src/actions, para ver qué queda sin probar.

[ ] Integración con Postgres

Correr una parte de las server actions contra una base real (la del worktree) para cubrir restricciones únicas, cascadas y transacciones que los mocks no ven.

[ ] Regresión visual

Comparar las capturas de pnpm screenshot contra las de main y marcar las diferencias en píxeles.

## Repositorio de casos de prueba

Todo lo que se prueba en el sitio, área por área. Los casos manuales son los que corremos a mano antes de llevar cambios a producción; los automatizados salen directo de la suite de Jest (y Playwright), con el archivo y el comando para correr cada uno. Podés linkear un caso con #TC-GAL-001.