Probar APIs con Cypress va más allá de un simple GET. Cuando aprendes a encadenar peticiones POST, PUT y DELETE con cy.request, empiezas a construir flujos de prueba reales que reflejan cómo se usa una API en producción. Aquí verás cómo crear, validar, modificar y eliminar un registro dentro de una misma suite, manteniendo limpia tu base de datos.

¿Cómo crear un registro con cy.request y método POST?

El primer paso es montar la estructura base con describe e it dentro de un archivo request.spec. A diferencia de un GET, aquí necesitas declarar explícitamente el verbo HTTP y enviar un cuerpo válido.

Dentro del cy.request pasas un objeto con tres propiedades clave:

• url: el endpoint, en este caso employees [01:30].
• method: el verbo HTTP, que para creación es POST.
• body: el objeto JSON con los datos del nuevo empleado.

Una vez enviada la petición, encadenas un .then(response => {}) para correr tus aserciones. Las dos validaciones mínimas son el código de estado y la presencia del identificador devuelto.

¿Qué significa el código 201 en una API? Es la respuesta estándar que indica que un recurso fue creado exitosamente tras un POST. Si tu API devuelve 201, sabes que el registro entró bien a la base de datos.

Para confirmar que el servidor generó el registro, validas con expect(response.body).to.have.property('id'). Esto te garantiza que la API no solo respondió, sino que asignó un identificador único al nuevo empleado [03:45].

¿Cómo guardar el ID de un registro para reutilizarlo en otras pruebas?

Aquí entra una técnica muy útil: guardar el ID generado en el contexto de Cypress para usarlo en los it posteriores. Esto evita tener que buscar manualmente el último registro en cada prueba.

Dentro del .then del POST, extraes const id = response.body.id y luego usas cy.wrap(id).as('id'). Con eso, ese valor queda disponible como this.id en el resto de la suite [05:50].

En el siguiente it validas que el registro exista en la base de datos. Haces un GET al endpoint y compruebas que el último elemento del arreglo coincida con lo que enviaste:

• Accedes a response.body[response.body.length - 1].
• Restas uno porque los arreglos empiezan en índice cero.
• Validas la propiedad firstname con to.equal contra el dato enviado.

Después de un bloque tan técnico, vale la pena pausar: este patrón de "crear y luego verificar" es la base de las pruebas end to end de APIs y lo vas a repetir muchísimo.

¿Cómo modificar un registro con el método PUT?

Para editar el empleado, reutilizas el ID guardado mediante interpolación de cadenas en la URL: `${url}employees/${this.id}`. El método cambia a PUT y el body lleva los nuevos valores, por ejemplo firstname: 'Pepito', lastname: 'Desarrollador' y un email actualizado.

Las aserciones esperadas son:

• response.status igual a 200, porque es una edición exitosa, no una creación.
• response.body con la propiedad id presente.
• Opcionalmente, validar que los campos modificados coincidan con lo enviado.

¿Cuál es la diferencia entre POST y PUT en pruebas de API? POST crea un recurso nuevo y devuelve 201. PUT modifica un recurso existente identificado por su ID y devuelve 200 cuando la edición es exitosa.

Un detalle importante: cuando uses this.id dentro del callback, asegúrate de no usar arrow functions si necesitas acceder al contexto de Mocha, o pasa el contexto correctamente.

¿Cómo eliminar el registro al final de la prueba con DELETE?

Dejar registros basura en la base de datos es un mal hábito, sobre todo si pruebas contra ambientes compartidos. Por eso cierras el flujo con un cy.request de tipo DELETE.

La estructura es la más simple de todas:

• url con el ID interpolado, igual que en el PUT.
• method: 'DELETE'.
• Sin body, porque un delete no requiere cuerpo.
• Validación: response.status igual a 200 [11:20].

Al correr la suite completa, deberías ver tres pasos: creación, validación de existencia, modificación y borrado. Al final, la base de datos queda exactamente como estaba antes de la prueba.

¿Cómo automatizar la limpieza con hooks de Cypress?

El reto que te queda es mover el DELETE a un hook como after o afterEach, y posiblemente el POST a un before. Así separas la preparación y limpieza del escenario real que estás probando, siguiendo el patrón AAA (Arrange, Act, Assert).

Esto vuelve tus pruebas más legibles y resistentes a fallos: aunque una aserción intermedia rompa, el hook de limpieza se ejecuta de todos modos y tu base de datos queda intacta.

¿Te animas a refactorizar el ejemplo usando hooks? Comparte tu código en los comentarios y cuéntanos cómo organizaste la creación y el borrado del registro.