Pruebas de contrato (contract testing)

Las pruebas de contrato comprueban de forma aislada el acuerdo entre dos servicios. Cada lado se prueba contra una descripción compartida de las interacciones, el contrato, en lugar de contra el otro servicio en ejecución. Si el proveedor cambia el nombre de un campo del que depende un consumidor, una prueba de contrato falla en el propio pipeline del proveedor, antes de desplegar nada. En coste y en confianza, se sitúan entre las pruebas de integración y las end-to-end.

Cómo funcionan las pruebas de contrato dirigidas por el consumidor

La forma más común, popularizada por la herramienta Pact, es la dirigida por el consumidor (consumer-driven):

1. El consumidor escribe una prueba contra un proveedor simulado (mock), indicando las peticiones que envía y las partes de la respuesta que realmente usa. Por ejemplo: GET /orders/42 devuelve 200 con un id numérico y un status de tipo string.
2. Al ejecutar esa prueba se genera un archivo de contrato (un “pact”) que registra esas interacciones.
3. El contrato se comparte, normalmente a través de un servicio broker.
4. El proveedor verifica el contrato reproduciendo cada petición registrada contra su implementación real y comprobando que las respuestas coinciden.
5. Antes de desplegar, el equipo comprueba que la versión que va a publicar es compatible con las versiones del otro lado que ya están en ese entorno.

Como el consumidor solo enumera los campos que usa, el proveedor es libre de añadir campos o cambiar cualquier cosa de la que no dependa ningún consumidor.

En qué se diferencia de otras verificaciones

• La validación de esquema comprueba una respuesta contra el esquema publicado por el proveedor. Te dice que el proveedor es coherente con su propia documentación, no que siga cubriendo las necesidades de cada consumidor.
• Las pruebas de integración llaman al proveedor real. Necesitan ambos servicios y sus dependencias en ejecución, y suelen ser más lentas e inestables.
• Las pruebas end-to-end demuestran que un recorrido completo funciona, pero son una forma lenta y cara de descubrir que se renombró un campo.

Los contratos dirigidos por el proveedor, donde el proveedor publica una especificación OpenAPI y los consumidores prueban contra ella, son una alternativa cuando el proveedor no puede conocer a todos sus consumidores ni coordinarse con ellos, como ocurre con una API pública.

Errores comunes

• Especificar demasiado. Comprobar valores exactos o todos los campos convierte los contratos en pruebas funcionales frágiles. Usa matchers de tipo e incluye solo lo que el consumidor lee.
• Probar lógica de negocio en los contratos. Los contratos comprueban la forma de la conversación; la corrección corresponde a las propias pruebas del proveedor.
• Saltarse los provider states. “El pedido 42 existe” debe prepararse en el lado del proveedor durante la verificación, o la verificación fallará por el motivo equivocado.