Validar headers en Cypress te permite confirmar que una API responde con el formato correcto antes de seguir construyendo pruebas más complejas. Aquí aprenderás a usar el método cy.request() para consultar un endpoint, acceder a la propiedad headers y verificar que el content-type devuelva un JSON, una habilidad clave para automatizar pruebas de APIs.

Por qué configurar una baseUrl antes de probar headers

Antes de escribir la primera aserción, conviene preparar el terreno. Una baseUrl evita que repitas la dirección completa del servidor en cada prueba y mantiene tu suite limpia.

En el archivo de configuración de Cypress defines la dirección de tu servidor local. Si tienes corriendo localhost en el puerto 3000, declaras http://localhost:3000 como baseUrl y a partir de ahí solo necesitas indicar el endpoint en cada prueba.

¿Qué es la baseUrl en Cypress? Es la dirección base que Cypress concatena automáticamente con cada endpoint que pases a comandos como cy.visit() o cy.request(). Te ahorra escribir la URL completa en cada test.

Dentro de la carpeta de integraciones creas un archivo nuevo llamado headers.spec.js. El sufijo .spec no es decorativo: Cypress lo necesita para reconocer el archivo como una prueba ejecutable.

Cómo hacer una petición con cy.request en Cypress

La estructura base de la prueba arranca con un describe que agrupa el escenario y un it que describe la validación específica, en este caso debe validar el header y el content type.

El comando estrella aquí es cy.request(). Como su nombre indica, sirve para hacer peticiones HTTP directas a un endpoint, sin necesidad de cargar una interfaz visual. Le pasas como argumento el endpoint, por ejemplo employees, y Cypress lo combina con la baseUrl que ya definiste.

Al ejecutar la prueba en Cypress notarás algo curioso: el panel del navegador aparece vacío. Eso es esperado, porque cy.request() no renderiza una página. La información vive en la consola del inspector, donde al hacer clic sobre el comando puedes ver:

• El request que se envió y su destino.
• El status devuelto, idealmente 200 si la petición fue exitosa.
• El tiempo de respuesta.
• El body, los headers y el status code completos.

Cómo validar el content-type con its y should

Una vez que tienes la respuesta, necesitas acceder a una propiedad específica para hacer la aserción. Cypress te da el comando its() para navegar dentro del objeto que devuelve el request.

¿Cómo accedo a los headers de una respuesta en Cypress? Encadenas .its('headers') después de cy.request() y luego .its('content-type') para llegar al valor exacto que quieres validar.

El flujo queda así: primero pides el endpoint con cy.request('employees'), luego accedes a la propiedad headers, después entras a content-type y finalmente aplicas la aserción con should('include', 'application/json').

javascript describe('probando headers', () => { it('debe validar el header y el content type', () => { cy.request('employees') .its('headers') .its('content-type') .should('include', 'application/json') }) })

El uso de include en lugar de una igualdad estricta es intencional. El header content-type suele venir acompañado de información extra como el charset, así que validar que incluya application/json es más robusto que exigir una coincidencia exacta.

Qué te confirma esta aserción

Cuando la prueba pasa, Cypress te indica que el endpoint está respondiendo con el formato esperado. Esto es valioso porque:

• Garantiza que el servidor devuelve datos en JSON y no en otro formato.
• Detecta cambios accidentales en la API antes de que rompan el frontend.
• Sirve como base para pruebas más profundas sobre el body de la respuesta.

¿Para qué sirve validar headers en pruebas de API? Los headers describen cómo viaja la información: tipo de contenido, autenticación, cacheo. Validarlos te asegura que la API se comporta según el contrato acordado.

En la siguiente clase darás un paso más: aplicar aserciones sobre el status code, una pieza clave para confirmar si una petición se resolvió de forma exitosa o si falló intencionalmente cuando esperas un error. ¿Qué otros headers te gustaría validar en tus propias pruebas?