Validar el body de una respuesta API en Cypress te permite confirmar que el servidor devuelve exactamente los datos esperados, no solo un status code correcto. Esta práctica es clave para automatizar pruebas robustas que verifiquen contenido real, encabezados y códigos de estado en una sola ejecución.

Cuando trabajas con APIs, el status code te dice si la petición fue exitosa, pero no si la información es la correcta. Ahí entra la validación del body: el cuerpo de la respuesta donde viaja la data que tu aplicación realmente consume.

¿Cómo se estructura una prueba de body en Cypress?

Todo arranca creando un archivo nuevo, en este caso llamado body.cy.js, dentro del proyecto de Cypress. La estructura sigue el patrón clásico con describe e it, donde describes el bloque como "Probando el body" y agrupas dentro las pruebas individuales.

javascript describe('Probando el body', () => { it('Probando body', () => { cy.request('/employees/1') .its('body') .its('first_name') .should('be.equal', 'Javier') }) })

El flujo es directo: haces el cy.request al endpoint /employees/1, encadenas .its('body') para acceder al cuerpo de la respuesta, luego .its('first_name') para extraer la propiedad y finalmente .should('be.equal', 'Javier') como aserción.

¿Qué hace el comando its en Cypress? Permite acceder a una propiedad específica de un objeto dentro de la cadena de comandos. Si tienes el body de una respuesta, its('first_name') te entrega solo ese campo para validarlo.

¿Cómo validar status code, headers y body en una sola prueba?

La magia aparece cuando combinas todas las validaciones en un solo bloque usando .then(). Este comando recibe la respuesta completa y te deja ejecutar múltiples aserciones sobre distintas partes: estado HTTP, encabezados y cuerpo.

javascript cy.request('/employees/1').then((response) => { expect(response.status).to.be.equal(200) expect(response.headers['content-type']) .to.be.equal('application/json; charset=utf-8') expect(response.body.first_name).to.be.equal('Javier') expect(response.body.last_name).to.be.equal('Apellido') })

Con esta estructura validas tres capas de la respuesta al mismo tiempo:

• El status code igual a 200, que confirma una petición exitosa.
• El content-type igual a application/json; charset=utf-8, que verifica el formato de respuesta.
• Las propiedades del body como first_name y last_name, que confirman los datos del registro.

¿Por qué usar then en lugar de its? then te da acceso al objeto completo de la respuesta, no solo a una propiedad. Eso te permite validar status, headers y body en el mismo callback, algo imposible con its encadenado.

¿Qué diferencia hay entre validar status y validar body?

Validar el status code te dice si la comunicación con el servidor fue correcta a nivel HTTP. Validar el body te dice si los datos que regresan son los correctos a nivel de negocio. Una API puede devolver un 200 con información incorrecta, y solo la validación del cuerpo lo detecta.

¿Qué propiedades del body conviene validar en una API?

Depende del recurso, pero hay un patrón común. Si trabajas con un endpoint de empleados, validar nombre y apellido es básico, pero puedes ir más allá y comprobar campos numéricos, fechas o incluso la ausencia de propiedades sensibles.

Algunas validaciones útiles que puedes experimentar:

1. Que una propiedad exista en el body.
2. Que una propiedad no exista (útil para datos privados).
3. Que el tipo de dato sea el esperado, por ejemplo número o string.
4. Que un array tenga cierta longitud.
5. Que valores específicos coincidan con la base de datos.

Un detalle práctico: cuando un apellido o valor contiene caracteres especiales, conviene copiarlo directo desde la base de datos y pegarlo en la prueba para evitar errores de codificación.

¿Qué herramientas y conceptos clave aparecen en esta práctica?

Durante el ejercicio se combinan varios elementos del ecosistema de pruebas que vale la pena tener claros:

• describe e it: bloques de Mocha que organizan suites y casos de prueba.
• cy.request: comando de Cypress para hacer peticiones HTTP a una API.
• its: accede a una propiedad de un objeto en la cadena de comandos.
• then: ejecuta una función con la respuesta completa para múltiples aserciones.
• should y be.equal: aserciones que comparan valores esperados contra reales.
• status code 200: indica que la petición HTTP fue exitosa.
• content-type application/json; charset=utf-8: formato y codificación estándar para APIs REST.

La habilidad central que desarrollas aquí es la de componer aserciones múltiples sobre una misma respuesta, algo que diferencia una prueba superficial de una verdaderamente útil en un pipeline de QA.

¿Qué propiedades del body validarías tú en tus propias APIs? Comenta cómo estructurarías la prueba y qué casos límite agregarías.