Contract testing: que la API no rompa a quien la usa

La API que funciona y rompe todo

Un equipo cambia el campo monto por total en la respuesta de su API, porque "se entiende mejor". Sus tests pasan: la API responde 200 con datos correctos. Esa misma tarde, la app móvil muestra los pedidos en $0 y el sistema de facturación deja de emitir boletas. Nadie rompió la API; rompieron el contrato.

Un contrato es la forma de la respuesta que otros sistemas esperan: qué campos trae, de qué tipo y cuáles son obligatorios. El contract testing verifica que esa forma no cambie sin aviso.

El test de contrato en Postman

Postman puede validar una respuesta contra un esquema JSON en una línea:

const esquema = {
  type: 'object',
  required: ['id', 'estado', 'monto', 'items'],
  properties: {
    id: { type: 'integer' },
    estado: { type: 'string', enum: ['pendiente', 'pagado', 'despachado', 'anulado'] },
    monto: { type: 'number', minimum: 0 },
    items: {
      type: 'array',
      items: {
        type: 'object',
        required: ['producto', 'cantidad'],
        properties: { producto: { type: 'string' }, cantidad: { type: 'number' } },
      },
    },
  },
};

pm.test('La respuesta cumple el contrato del pedido', () => {
  pm.response.to.have.jsonSchema(esquema);
});

Con eso, el renombre de monto a total falla en el pipeline, antes de llegar a producción. Corriendo la colección con Newman en CI, como en la lección anterior, el contrato se verifica en cada cambio.

Qué rompe y qué no

El último caso es el más traicionero: un estado nuevo, "en_revision", no rompe el esquema de quien produce la API, pero sí puede romper a un consumidor que solo conocía cuatro estados.

Dirigido por el consumidor

Un paso más allá es el contract testing dirigido por el consumidor: cada sistema que usa la API declara qué partes usa de verdad, y el equipo que mantiene la API verifica, antes de cada cambio, que no rompe ninguna de esas declaraciones. Herramientas como Pact automatizan esa idea. La ventaja: el proveedor sabe exactamente qué puede cambiar con tranquilidad y qué no.

Si la API tiene una especificación OpenAPI, el contrato tiene que salir de ahí: una sola fuente para la documentación, los mocks y los tests.

Por qué va a importar en Chile

Desde julio de 2027, el Sistema de Finanzas Abiertas empieza a operar según la NCG N°569 de la CMF: bancos y otras instituciones van a exponer APIs reguladas, con un anexo técnico que define sus especificaciones, un periodo piloto y un sandbox (ATENA) para probar antes.

En ese mundo, el contrato no es una buena práctica: es la especificación con la que otras empresas construyen sus productos. Un campo renombrado no rompe una app propia, rompe a terceros regulados. Saber escribir y mantener tests de contrato va a ser parte del trabajo de QA en banca y fintech.

Cierre del curso

Fundamentos, requests, colecciones, variables, encadenamiento, aserciones, data-driven, CI y contratos: tienes el stack completo de API testing. El siguiente paso natural es sumarlo a tu automatización e2e (Playwright también prueba APIs) y practicar en el playground de automatización.

Comprueba lo aprendido en el quiz y escribe el contrato de un endpoint en el reto final.