Skip to main content

Testing del backend

proteus-backend tiene suite de jest (jest.config.ts, ~144 archivos .test.ts). El frontend usa Karma/Jasmine pero prácticamente no tiene tests.

npm test                        # toda la suite
npx jest tests/integration      # solo integración HTTP
npx jest tests/integration/patient
npm run test:postgres           # SPs contra Postgres real (--runInBand)
npm run test:mysql              # SPs contra MySQL real
npm run test:migration          # migración (los estructurales no necesitan DB)
QUIET_TESTS=0 npx jest ...      # ver los console.* reales al depurar
El CLAUDE.md del repo dice que no hay test runner

Está desactualizado. Hay jest.config.ts, npm test y ~144 archivos .test.ts en tests/.

Las tres familias​

tests/unit/​

Unitarios puros. Ejemplo: unit/permissions.

tests/integration/​

Un directorio por módulo o service. Ejercitan el borde HTTP real con supertest: el controller, el pipeline de validación de routing-controllers y el CustomErrorHandler de producción.

No tocan red ni base: mockean los bordes (AjoloteService, AccessService, el service del módulo) con jest.mock. Validan dos cosas:

  1. que class-validator funcione (requeridos, tipos, formatos, rangos);
  2. que los errores handleados vuelvan con el status y la forma correctos.

Módulos cubiertos: auth, atention-process, authorization, capita, document, health-center, insurance, patient, patient-agreement, permissions, rules-engine.

Helpers compartidos en tests/integration/helpers/:

HelperQué da
testApp.tsbuildTestApp(controllers, opts?): una app Express mínima con el SecurityMiddleware real, la validación real y el CustomErrorHandler real
authMock.tsBEARER, AUTH_USER, LOCAL_USER, makeAjoloteMock(), makeAccessAuthMock(), primeHappyAuth(ajolote, access)
validateDto.tsvalidateDto(cls, payload), constraintsFor, hasError — testear un DTO sin levantar el server
No edites los helpers compartidos desde un test de módulo

Si necesitás algo extra, va como helper local en la carpeta de tu módulo.

tests/migration/​

Caracterización de stored procedures contra una base real. El motor se elige con TEST_DB_ENGINE=mysql|postgres. Es la red de seguridad de la migración a Postgres.

Variante: validar SQL crudo contra el schema real​

Para un service de SQL crudo hay un tercer tipo de red útil: capturar el SQL que genera y planificarlo con EXPLAIN (GENERIC_PLAN) (Postgres 16+), que valida una consulta con $n sin ejecutarla ni bindear params.

No necesita que las tablas tengan datos y caza tabla o columna inexistente, sintaxis, función que no existe y tipos incompatibles.

Molde: tests/integration/control-dashboard/control-dashboard-sql.test.ts (42 queries de 8 endpoints). Se gatea con hasTestDatabase(), igual que los tests de SPs. Receta completa en Porteo de SQL.

Config​

preset: ts-jest · roots: tests/ · testMatch: **/*.test.ts · testTimeout: 60s · setupFiles: [reflect-metadata, loadEnv] (TypeORM necesita reflect-metadata) · setupFilesAfterEach: quietConsole (silencia el ruido de console.* del código de producción) · moduleNameMapper que replica los alias de paths.

Gotchas​

  • El archivo debe terminar en .test.ts (no .spec.ts), o jest no lo descubre.
  • Un alias nuevo hay que agregarlo también al moduleNameMapper de jest.config.ts, no solo a tsconfig.json y AppConfig.ts. Ver Arquitectura.
  • Los tests de SP corren --runInBand a propósito: comparten la base.
  • Los módulos ESM-only rompen ts-jest (file-type fue el caso). Se resuelven con un mock virtual en el test.
  • Un service "v2" muy acoplado puede no ser unit-testeable en aislamiento. En esos casos el test de integración HTTP es la única cobertura razonable: no fuerces el unitario.