Validar el status code en Cypress es una de las acciones más críticas al probar una API, porque define si el servidor respondió como esperabas. Aquí aprenderás a verificar respuestas exitosas, manejar errores 404 y configurar Cypress para que no detenga tus pruebas cuando buscas validar fallos.

¿Cómo crear un archivo de pruebas para status codes en Cypress?

Dentro de la carpeta de integración creas un archivo nuevo, por ejemplo status.spec, y ahí defines el bloque principal con describe("Probando statuses"). Ese contenedor agrupa todas las validaciones relacionadas con códigos de respuesta.

Dentro del describe, abres tu primer it con un mensaje claro como debe validar el status code exitoso. Esa nomenclatura ayuda a que cualquier persona del equipo entienda qué se está probando con solo leer el log [0:35].

¿Cómo validar un status code 200 exitoso?

El flujo es directo: haces un cy.request al endpoint employees, accedes con .its('status') y encadenas un .should('equal', 200). Cuando el servidor responde correctamente, esa aserción pasa sin problema.

¿Qué significa un status code 200? Es la respuesta estándar del servidor cuando la petición HTTP se completó con éxito. En Cypress, lo validas comparando its('status') contra 200.

Al abrir el navegador de Cypress puedes inspeccionar la consola y confirmar que el valor esperado y el obtenido coinciden. Esa visibilidad es clave para depurar pruebas de API rápido [1:45].

¿Por qué Cypress falla cuando esperas un status code 404?

Cuando intentas validar un recurso que ya no existe, por ejemplo el empleado 4 que fue eliminado, Cypress lanza un error automáticamente aunque tu código diga .should('equal', 404). El log muestra el detalle del fallo, la URL afectada y el código recibido.

Esto ocurre porque Cypress, por defecto, considera cualquier respuesta fuera del rango 2xx como un fallo de la prueba. Es una medida preventiva pensada para que no pases por alto errores reales del servidor [2:50].

¿Cómo desactivar failOnStatusCode en Cypress?

La solución es transformar el argumento de cy.request de una simple cadena a un objeto de configuración. En ese objeto especificas la propiedad url y agregas failOnStatusCode: false.

El bloque queda así:

javascript cy.request({ url: '/employees/4', failOnStatusCode: false }).its('status').should('equal', 404)

Con esa bandera en false, le indicas a Cypress que no marque la prueba como fallida cuando reciba un código de error. Ahora puedes confirmar que tu API devuelve un 404 cuando el recurso no existe, que es exactamente el comportamiento esperado [3:30].

¿Cuándo debo usar failOnStatusCode false? Úsalo cuando tu objetivo es probar respuestas de error como 400, 401, 404 o 500. Si lo dejas activo, Cypress detendrá la prueba antes de que llegues a tu aserción.

¿Qué otros status codes puedes validar en tus pruebas?

La lógica que aprendiste con 200 y 404 se replica para cualquier código HTTP. Solo cambias el número en la aserción y, si esperas un error, ajustas la configuración de la petición.

Algunos códigos comunes que vale la pena cubrir en tus pruebas:

• 200: petición exitosa.
• 201: recurso creado correctamente, típico en POST.
• 400: petición mal formada por el cliente.
• 401: falta de autenticación.
• 404: recurso no encontrado.
• 500: error interno del servidor.

Validar el status code es el primer filtro, pero no el único. Hay casos donde tu API responde con un 200 y aun así el body trae datos incorrectos o incompletos, así que la siguiente capa de pruebas se enfoca en validar el contenido de la respuesta.

¿Qué status code probaste con tu propia API? Déjalo en los comentarios y comparte cómo lo configuraste.