🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónPruebas de contrato en CI
5 tareas · 38 min · Principiante
Un contrato que nadie comprueba se desfasa de la API real en pocas semanas. Tres controles automáticos lo mantienen honesto: el linter lee el contrato, la comparación entre versiones avisa de lo que cambió y las pruebas de contrato contrastan la API con lo escrito. En Mayoristas Boquerón lees el pipeline y la salida de cada control y decides si de verdad frena un cambio malo. Todo es lectura de archivos y de salidas simuladas; no se ejecuta nada.
Objetivo de la sala
Un contrato que nadie comprueba se desfasa de la API real en pocas semanas. Tres controles automáticos lo mantienen honesto: el linter lee el contrato, la comparación entre versiones avisa de lo que cambió y las pruebas de contrato contrastan la API con lo escrito. En Mayoristas Boquerón lees el pipeline y la salida de cada control y decides si de verdad frena un cambio malo. Todo es lectura de archivos y de salidas simuladas; no se ejecuta nada.Cada control responde a algo distinto. El linter pregunta si el contrato cumple las reglas del equipo. La comparación entre versiones pregunta qué cambió respecto a la anterior y si ese cambio rompe a quienes ya consumen la API. Las pruebas de contrato pregunta si el servicio real responde como dice el contrato (códigos, campos, tipos).
Ninguno sustituye a los otros: el linter no ve la API, la comparación no ve su comportamiento y las pruebas no ven las reglas del equipo.
Responde para continuar
¿Qué control detecta que la API real devuelve un campo que el contrato no declara?
Ver pista de ayuda
Solo uno de los tres mira la respuesta de la API en funcionamiento.
En un pipeline, un trabajo con allow_failure: true puede fallar sin detener nada: el resultado queda como «advertencia» y nadie lo mira si no hay una política que lo exija. A veces es legítimo para un control que se está introduciendo; sin fecha para volverlo bloqueante es un control decorativo.
Lee el pipeline del repositorio y busca el trabajo que puede fallar sin frenar el cambio.
Responde para continuar
Escribe el nombre del trabajo del pipeline que tiene allow_failure activado.
Ver pista de ayuda
Con la terminal, `cat .gitlab-ci.yml` y busca la clave `allow_failure`.
La comparación entre versiones clasifica cada cambio. Un cambio incompatible rompe a quien ya integró la API: se elimina una operación, se añade un parámetro obligatorio, cambia el tipo de un campo. Se publican con una versión mayor nueva o con un aviso a los consumidores, no por sorpresa.
La salida de este laboratorio está escrita a mano: no es de ninguna herramienta real, pero sigue la forma de las que sí existen.
Responde para continuar
¿Cuántos cambios de la comparación están clasificados como incompatibles?
Ver pista de ayuda
Abre `salida/diferencias-pedidos.txt` y cuenta las líneas marcadas `incompatible`.
Quitar un requisito de seguridad a una operación no rompe a ningún consumidor: todos siguen funcionando, y por eso una comparación de compatibilidad lo clasifica como compatible. Es un cambio de seguridad grave que ese tipo de control no sabe valorar. La revisión humana, o una regla específica que alerte de cualquier requisito eliminado, debe cubrir esa mirada.
Lee la comparación y busca el cambio que quita el requisito de seguridad.
Responde para continuar
Escribe el identificador del cambio que quita un requisito de seguridad.
Ver pista de ayuda
Busca la palabra security en `salida/diferencias-pedidos.txt`.
El pipeline del repositorio solo se dispara con main, es decir, después de fusionar. Un control que corre tras la fusión avisa cuando el cambio ya está en la rama principal y quizá ya desplegado. Para frenar de verdad, los controles corren en la solicitud de fusión y su resultado es condición para fusionar.
Responde para continuar
El pipeline corre solo en main. ¿Qué cambio lo convierte en un control que frena?
Ver pista de ayuda
Compara el momento en que corre el control con el momento en que el cambio queda fusionado.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.