Express.js
End-to-end testing
Explica cómo verificar flujos completos sobre el artefacto desplegado, red, base de datos, workers y servicios de prueba sin depender de datos manuales.
- Última actualización
- Actualizada
- Nivel
- Profundización
Express.js
Explica cómo verificar flujos completos sobre el artefacto desplegado, red, base de datos, workers y servicios de prueba sin depender de datos manuales.
Una prueba end-to-end verifica un flujo desde un cliente realista hasta las dependencias desplegadas. Su valor está en cubrir integración completa; su coste está en velocidad, datos y diagnóstico.
cliente/test runner
↓ red real
proxy o servidor
↓ Express
PostgreSQL + broker + servicios de test
↓
resultado observableNo todo test que usa Supertest es E2E. E2E normalmente ejecuta el artefacto como se despliega y atraviesa límites reales.
Unit e integration tests pueden pasar mientras producción falla por:
E2E detecta estas diferencias.
Un flujo útil podría ser:
No intentes cubrir cada validación en E2E; eso pertenece a capas más rápidas.
Opciones:
Un entorno compartido introduce colisiones y dependencia temporal. Los entornos efímeros cuestan más, pero aíslan.
Usa identificadores únicos y cleanup:
const testRunId = crypto.randomUUID();
const email = `e2e-${testRunId}@example.test`;Evita depender de datos manuales. El setup puede utilizar APIs administrativas protegidas o seeds versionados.
No llames pagos o email reales. Usa:
El fake debe reproducir timeouts, errores y firmas relevantes, no solo happy path.
No uses sleeps fijos largos. Poll con deadline:
await waitFor(async () => {
const report = await api.getReport(id);
return report.status === 'completed';
}, { timeoutMs: 20_000, intervalMs: 250 });Registra el último estado cuando falla.
Causas frecuentes:
Un test flaky reduce confianza. No lo ignores; aísla causa, mejora diagnóstico o retíralo temporalmente con owner y fecha.
Verifica resultados del usuario y sistema:
No consultes DB directamente para todo porque podrías saltarte el comportamiento público, aunque puede ayudar en setup o diagnóstico.
Escenarios críticos:
Pentesting y análisis de seguridad siguen siendo capas distintas.
Smoke tests después del deploy:
/health/ready.Si fallan, deployment puede detenerse o revertirse según riesgo.
Divide suites por recursos aislados. No ejecutes tests que actualizan el mismo pedido en paralelo. Crea tenant por worker cuando sea posible.
Cuando falla captura:
Un error “expected 200 got 500” sin contexto es insuficiente.
La forma exacta importa menos que equilibrar:
E2E no debe ser la única red de seguridad.
Flujo DomiSys:
No todos se ejecutan en cada PR; algunos pertenecen a suites programadas o chaos testing.
Estructura del proyecto Express organiza los boundaries verificados por estas capas de pruebas.