Entrevista de backend: ¿Cómo usarías pruebas de contrato guiadas por el consumidor para lanzar una API de microservicios de forma segura?

Planteamiento y alcance

Un proveedor de órdenes atiende a consumidores web, móviles y asíncronos. El equipo quiere detectar cambios incompatibles (breaking changes) antes de lanzar el proveedor, sin tener que iniciar todos los servicios reales para cada commit. Diseña un flujo de trabajo de contratos guiados por el consumidor: qué escriben los consumidores, cómo verifican los proveedores, cómo selecciona las versiones un broker, cómo funcionan los estados del proveedor y cuándo se permite el despliegue.

Esto evalúa los límites de la API, la estratificación de pruebas, la compatibilidad de versiones y la entrega continua. Pact modela un contrato como la solicitud requerida por el consumidor y la respuesta mínima esperada, y luego la reproduce contra el proveedor; no reemplaza las pruebas unitarias, de integración o de extremo a extremo (E2E).

Qué está evaluando el entrevistador

• Si el comportamiento del consumidor se convierte en un contrato de interacción mínimo en lugar de una copia de la implementación del proveedor.
• Si puedes conectar pruebas simuladas del consumidor, verificación del proveedor, un broker y una matriz de despliegue.
• Si los estados del proveedor aíslan las precondiciones sin depender del orden en una base de datos compartida ni de credenciales de producción.
• Si manejas múltiples versiones de consumidores, contratos no verificados, contratos de mensajes y reversiones (rollbacks).

Preguntas para clarificar primero

1. ¿La interfaz es HTTP, mensajería asíncrona o ambas? El medio portador del contrato difiere.
2. ¿Qué campos utilizan realmente los consumidores? El contrato debe expresar solicitudes requeridas y respuestas mínimas.
3. ¿Pueden los estados del proveedor crear, limpiar y parametrizar datos de prueba? ¿Qué dependencias necesitan stubs?
4. ¿Cómo se identifican las versiones y qué combinaciones de consumidor/proveedor deben pasar antes de ir a producción?
5. ¿Existe un broker, etiquetado de ramas (branch tagging), política de pactos pendientes (pending pacts) y estrategia de reversión?

Una estructura de respuesta en 30 segundos

Los consumidores escriben pruebas de interacción contra un mock de Pact, produciendo un contrato que contiene solo las aserciones indispensables de solicitud y respuesta; luego lo publican en un broker. Un verificador del proveedor selecciona las versiones objetivo del consumidor, configura los estados del proveedor, reproduce las solicitudes en un entorno aislado y publica los resultados. La compuerta de despliegue de CI valida la matriz de versiones real; un contrato nuevo no verificado puede quedar como pendiente o bloquear el lanzamiento. Los contratos demuestran la estructura del mensaje y la interacción, no toda la corrección del negocio. Ante una falla, se detiene el despliegue, se corrige el proveedor o se revierte a una versión que haya superado la matriz.

Respuesta paso a paso

1. Definir interacciones a partir del comportamiento del consumidor

Cada interacción describe el método, la ruta, los encabezados obligatorios, los campos importantes de la solicitud y las aserciones de respuesta mínimas. Las pruebas del consumidor llaman a un mock de Pact en lugar de a un proveedor real, produciendo un contrato rápido y compartible vinculado al uso real del consumidor.

consumer test -> pact file -> broker
provider verifier + provider state -> replay -> verification result
deployment gate -> compatible version matrix -> deploy or block

2. Mantener el contrato mínimo y estable

No hagas aserciones sobre campos de respuesta no utilizados, IDs aleatorios o una instantánea completa de la base de datos. Utiliza matchers para tipos, formatos y estructura obligatoria; valida únicamente la forma de marcas de tiempo dinámicas y UUIDs. Las pruebas de contrato se centran en los mensajes de comunicación, no en la funcionalidad genérica del proveedor.

3. Diseñar los estados del proveedor (provider states)

Un estado del proveedor es una precondición para la interacción, como "la orden está pagada". Un manejador de estado crea o simula datos antes de la verificación y los limpia después. Los parámetros deben ser rastreables e idempotentes sin requerir credenciales de producción; las interacciones no deben depender de una secuencia no controlada.

4. Administrar versiones y verificación en un broker

Los consumidores publican contratos con etiquetas de rama, versión o entorno. Los proveedores verifican las versiones de consumidor seleccionadas y publican los resultados. La compuerta de despliegue verifica el proveedor candidato frente a los consumidores que realmente se ejecutarán, no simplemente si la versión "latest" está en verde. El comportamiento de pendientes (pending) permite verificar y registrar un nuevo contrato antes de decidir si debe bloquear el pipeline.

5. Elegir el orden de despliegue y las ventanas de compatibilidad

Para un cambio compatible, despliega un proveedor que entienda las solicitudes antiguas y devuelva respuestas que los consumidores antiguos puedan leer, y luego actualiza los consumidores. Los cambios incompatibles requieren lecturas/escrituras duales, una ruta versionada o una ventana de migración. Los message pacts validan los puertos de mensajes, pero la entrega real en el broker, los reintentos y el ordenamiento todavía requieren pruebas independientes.

6. Gestionar fallas y observar en producción

Registra la interacción fallida, el estado del proveedor, las versiones, el SHA del commit y el entorno. Bloquea el despliegue y revierte a la última versión que haya superado la matriz; después del lanzamiento, monitorea errores 4xx/5xx, errores de deserialización, dead letters y métricas de negocio. Las pruebas de contrato en verde no prueban la corrección en producción, por lo que se debe mantener la protección en tiempo de ejecución.

Respuesta de ejemplo de alta calidad

Cada consumidor escribiría interacciones reales contra un mock de Pact, generando un contrato únicamente con las solicitudes requeridas y respuestas mínimas, y publicándolo en un broker. El verificador del proveedor selecciona las versiones del consumidor, ejecuta estados del proveedor repetibles de forma aislada, reproduce las solicitudes y publica el resultado junto con la versión del proveedor y el SHA del commit. La compuerta de CI comprueba si las versiones del consumidor y del proveedor que se ejecutarán juntas cuentan con evidencia de verificación; los pactos pendientes permiten verificar un nuevo contrato sin romper de inmediato un proveedor antiguo.

El contrato cubre la estructura de la comunicación y los campos utilizados, no todas las pruebas unitarias, de integración, E2E o de lógica de negocio. Despliega los lectores antes de modificar incompatiblemente a los escritores: mantén el proveedor compatible con solicitudes y respuestas antiguas, luego migra los consumidores; utiliza rutas versionadas o una ventana de doble escritura para cambios incompatibles. Ante una falla, bloquea el lanzamiento y regresa a la última matriz aprobada, manteniendo el monitoreo de errores en tiempo de ejecución, colas de mensajes no procesados (dead-letter) y métricas de negocio. Los message pacts cubren el contenido del mensaje, mientras que la semántica del broker de mensajería requiere pruebas separadas.

Modos de falla comunes

• Convertir el contrato en una instantánea completa de la respuesta del proveedor, haciendo que campos no relacionados bloqueen los lanzamientos.
• Ejecutar solo mocks del consumidor y nunca reproducir el contrato contra el proveedor.
• Hacer que los estados del proveedor dependan del orden en una base de datos compartida, datos aleatorios o credenciales de producción.
• Validar únicamente la última versión e ignorar la matriz de despliegue real y los clientes de cola larga (long-tail).
• Tratar a Pact como una suite de pruebas de extremo a extremo e ignorar el broker real, la autorización, el rendimiento y las reglas de negocio.
• Desplegar tras una falla de verificación o carecer de una versión verificable a la cual revertir.

Preguntas de seguimiento y respuestas de referencia

¿Por qué mantener mínimas las expectativas de respuesta?

Los consumidores solo deben acoplarse a los campos que utilizan. Las expectativas mínimas reducen el acoplamiento accidental y permiten a los proveedores agregar campos no relacionados de forma segura.

¿En qué se diferencia un estado del proveedor de un test fixture?

Un estado del proveedor es una interfaz de precondición ejecutable que el verificador puede configurar y limpiar en el entorno del proveedor. Un fixture es solo un artefacto de datos y puede no establecer correctamente el estado entre servicios.

¿Qué problema resuelve un pending pact?

Permite que un nuevo contrato ingrese al broker y sea verificado sin hacer fallar inmediatamente la compilación de un proveedor antiguo la primera vez que el contrato aparece sin verificar. Su habilitación depende de la política de lanzamientos de la organización.

¿Cómo se previene la proliferación descontrolada de contratos (contract sprawl)?

Deduplicando interacciones reales de los consumidores, retirando versiones antiguas, restringiendo campos aleatorios e instantáneas completas, y registrando el propietario, la versión y la última fecha de verificación en el broker.

¿Por qué es importante la selección de versiones del consumidor?

La compuerta debe verificar las versiones que coexistirán en ejecución. Comprobar únicamente main o latest puede pasar por alto una versión móvil o de rama más antigua que todavía está en producción.

¿Puede Pact demostrar la corrección del negocio en el proveedor?

No. Demuestra que las interacciones cumplen con los contratos de los consumidores. Las invariantes de negocio, el rendimiento, la autorización, la recuperación y la infraestructura real aún requieren otras pruebas y observación en producción.