Pruebas de contrato y lo que deliberadamente no verifican

Qué verifican las pruebas de contrato

Que la estructura que espera cada lado sea la misma. Nombres de campos, tipos, obligatorios y opcionales, códigos de estado. Si un productor elimina un campo del que depende un consumidor, las pruebas de contrato fallan en tiempo de compilación y no a las tres de la madrugada.

En un sistema con muchos servicios y despliegues independientes, esto es realmente valioso y mucho más económico que los entornos de integración de extremo a extremo.

Qué no verifican deliberadamente

• Si el valor es correcto. Una respuesta con la estructura correcta que contiene un total equivocado cumple todos los contratos.

• Si el flujo funciona. Cada llamada puede cumplir su contrato mientras la secuencia produce un resultado sin sentido.

• Lo que ve el usuario. Los contratos tratan de servicios que hablan con servicios. Nadie ha abierto el producto.

Nada de esto es una crítica. Una prueba de contrato que verificara valores quedaría acoplada a los datos y se rompería constantemente, que es justo lo que las pruebas de contrato se diseñaron para evitar. Ese alcance limitado es la ventaja.

El modo de fallo que hay que vigilar

Un equipo adopta las pruebas de contrato, los fallos de integración se detienen y la confianza sube. Seis meses después, algo se rompe en producción tras haber pasado todas las pruebas de contrato, porque la estructura era correcta y el comportamiento no. La lección que se suele sacar es que las pruebas de contrato fallaron, y esa es la lección equivocada.

Las pruebas de contrato hicieron su trabajo. El hueco estaba en que nada verificaba el comportamiento, y el éxito de la capa de contratos hizo que ese hueco fuera más difícil de ver.

Qué debe acompañarlas

Verificación funcional contra los servicios en ejecución: si la secuencia de llamadas produce el resultado correcto, si las rutas de error se comportan como deben, si la autorización se sostiene. Esa es otra capa y responde las preguntas que los contratos no pueden.

Esas verificaciones tienen que manejar sesiones, valores capturados entre llamadas, orden y limpieza, temas que se cubren en la documentación de pruebas de API.

Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.

El enfoque dirigido por el consumidor y por qué suele ganar

Los dos enfoques se diferencian en quién escribe el contrato, y la diferencia se nota un año después, no de inmediato.

Los contratos dirigidos por el productor codifican lo que el servicio pretende ofrecer. Eso es útil y tiende a ser generoso: el contrato describe la respuesta completa, incluidos campos que nadie consume. Entonces los cambios incompatibles en campos que no se usan hacen fallar la compilación, los equipos empiezan a ignorar los fallos de contrato y eso anula el propósito.

Los contratos dirigidos por el consumidor codifican lo que cada consumidor lee en realidad. El contrato es más pequeño, los fallos son reales y obtienes un subproducto genuinamente útil: un mapa preciso de qué campos le importan a quién. Ese mapa es lo que permite a un productor marcar algo como obsoleto con confianza, que es lo que todos querían en realidad.

Dónde se ejecuta cada una

Las pruebas de contrato, en tiempo de compilación, rápidas y en cada commit, porque todo su valor está en detectar las desviaciones de estructura antes de la integración. La verificación de comportamiento, contra un entorno desplegado, en cada pull request.

El disparador importa más que el mecanismo. Apuntarlo a tu evento de despliegue significa que cada cambio se verifica sin que nadie tenga que decidirlo; la GitHub App lo hace desde el panel, y un paso de GitHub Actions lo hace desde dentro de tu flujo de trabajo.

Lo que responde TestSprite y los contratos no pueden

Si los valores son correctos y si la secuencia produce el resultado correcto. Ejercita los servicios en ejecución a través de sus interfaces, de modo que se detecta una respuesta que cumple todos los contratos y contiene un total equivocado.

Los flujos de varios pasos son el hueco concreto. Integration Tests encadena llamadas donde una respuesta alimenta a la siguiente, y Dependency Chains deduce un orden seguro a partir de lo que cada caso necesita y produce. Auto-Authentication mantiene las sesiones vivas durante toda una ejecución, Dynamic Variables transporta valores entre llamadas, Dependency Chains deduce el orden de ejecución a partir de lo que cada caso necesita y produce, y Auto-Cleanup elimina exactamente lo que creó la ejecución.

Lo que acabas teniendo son dos capas que no se solapan: los contratos, que detectan las desviaciones de estructura en tiempo de compilación, a bajo costo y en cada commit, y la verificación de comportamiento, que cubre las preguntas de corrección a las que los contratos son deliberadamente ciegos.