Tests HTTP backend

Esta guía pone en marcha un entorno real de integración HTTP para el backend del ERP usando:

Express real
módulos reales
middleware real de auth y tenant
MariaDB real
Sequelize real

Estado actual

La suite vive en:

apps/server/src/testing/http

Script disponible:

cd /home/david/dev/factuges/factuges-erp
pnpm --filter @erp/factuges-server test:http

Entorno requerido

Docker y Compose disponibles desde WSL. El comando test:http crea su propia MariaDB 11.8.3 temporal, con puerto dinámico y credenciales generadas; elimina el proyecto y sus volúmenes al terminar.

La configuración de aplicación se carga desde apps/server/.env.test o, si falta, desde .env.test.example. El launcher siempre proporciona la conexión a la base temporal y el runtime rechaza destinos externos. Cada runtime crea una base única, prepara el esquema con las migraciones versionadas y arranca con DB_SYNC_MODE=none. No se requiere un servidor MariaDB de tests preexistente.

Ver base de datos local y migraciones para el contrato, recuperación y órdenes de validación.

Runtime reutilizable

Pieza principal:

apps/server/src/testing/http/http-test-runtime.ts

Responsabilidades:

cargar .env.test
resetear registries globales del server
validar configuración segura de test
crear la base temporal y ejecutar migraciones
arrancar la app real en un puerto efímero
exponer request() y stop()

Fixtures actuales

Helpers disponibles:

apps/server/src/testing/http/http-test-fixtures.ts

Cobertura inicial:

cuentas de identity
companies
memberships account-company
payment terms
login real por API
consulta directa a la fila persistida de companies

Suite piloto actual

Archivo:

apps/server/src/testing/http/companies-current.http.test.ts

Cobertura inicial confirmada:

GET /api/v1/companies/current
PATCH /api/v1/companies/current
401 sin auth
403 sin X-Company-Id
403 con membership inactiva
update parcial
limpieza explícita con null
asignación y desasignación de default_payment_term_id
default_payment_term_id cross-company => 422
default_payment_term_id inactivo => 422
rollback transaccional cuando falla la asignación de default_payment_term_id
422 por payload inválido

Convenciones prácticas

usar login real en vez de fabricar JWTs
sembrar solo los datos mínimos del caso
cerrar siempre el runtime con stop()
no compartir base de datos entre tests
validar tanto respuesta HTTP como persistencia cuando la mutación lo requiera

Contrato de `default_payment_term_id`

Semántica actual:

omitido -> conservar
null -> desvincular
UUID activo de la misma company -> asignar
UUID no asignable -> 422

Se considera no asignable:

un PaymentTerm de otra company
un PaymentTerm inactivo

Además, el PATCH /companies/current es transaccional:

si falla default_payment_term_id
no se persisten otros cambios del mismo request

3.0 KiB Raw Blame History