Pruebas de integración seguras

Una prueba de extremo a extremo recorre todos los servicios de un flujo a la vez: es lenta, frágil y poco precisa cuando falla. Una prueba de contrato comprueba un servicio frente a lo que sus consumidores esperan de él, sin levantar los demás. En una arquitectura dividida se necesitan ambas, con muchas más de contrato que de extremo a extremo.

Las pruebas de integración con datos reales son cómodas y peligrosas: cualquiera con acceso al entorno de pruebas ve datos de clientes, los registros del entorno los copian y una prueba mal escrita puede modificarlos. La regla es que los datos de un entorno de pruebas se fabrican para él; los de producción no se copian sin enmascararlos.

Abre ci/integracion.yml y pruebas/datos-de-prueba.txt.

Una identidad con todos los permisos hace pasar casi cualquier prueba, y por eso esconde errores de autorización: si todos los escenarios corren como administrador, nadie comprueba que un usuario normal no pueda ver lo ajeno. Una buena lista de escenarios usa varias identidades, incluidas las que deben ser rechazadas.

Abre pruebas/escenarios.csv.

Una prueba que no frena la tubería cuando falla se vuelve decoración: con el tiempo nadie mira su resultado. Es especialmente grave si es la que comprueba que los accesos prohibidos siguen prohibidos, porque su fallo significa que un permiso se abrió.

Lee el archivo de la tubería con atención a las opciones de cada trabajo.

El entorno de integración debe poder repetirse y no debe tener nada que perder. Eso significa datos sintéticos propios y, para los servicios de terceros, el entorno de pruebas que el proveedor ofrece, con sus tarjetas o credenciales de prueba. Enmascarar a mano cada ejecución falla el día que alguien se olvida; restringir el acceso a la réplica deja los datos reales en un entorno que no los necesita.