Validar que tu API y tu base de datos hablen el mismo idioma es una de las pruebas más valiosas que puedes hacer en QA. Cuando combinas requests HTTP con consultas SQL dentro de Cypress, confirmas que el dato que devuelve el endpoint coincide con el que vive en la base. Esa coherencia es la que sostiene la confianza en tu software.

¿Por qué probar API y base de datos juntas?

Las APIs se alimentan de bases de datos. Si tu API devuelve un monto formateado con el signo de peso, alguien tuvo que tomar el número crudo de la tabla y aplicarle ese parsing. Probar ambos extremos te permite detectar inconsistencias que una prueba aislada nunca vería.

Un flujo típico se ve así:

• Consultas el dato directamente en la base.
• Replicas la función que hace el parsing en tu test.
• Validas que la respuesta de la API coincida con ese valor procesado.

¿Qué valida una prueba combinada de API y base de datos? Confirma que la información persistida y la información expuesta por el endpoint son consistentes, incluyendo formato, tipo de dato y existencia del registro.

¿Cómo eliminar un registro y verificarlo en la base de datos?

El ejercicio arranca creando un nuevo archivo de pruebas con un describe llamado putting it all together. Dentro va un it con la intención clara: eliminar el registro creado y comprobar que ya no existe en la base.

¿Cómo enviar un DELETE con cy.request?

La idea es simular contra el servidor real, que debe estar corriendo localmente. Usas cy.request pasándole un objeto con la URL del recurso, el ID que quieres borrar y el método.

javascript cy.request({ url: 'employees/3', method: 'DELETE' }).then((response) => { expect(response.status).to.equal(200) })

El expect sobre response.status igual a 200 confirma que el servidor procesó la eliminación. Hasta aquí solo sabes que la API respondió bien, pero todavía no sabes qué pasó del otro lado.

¿Cómo confirmar la eliminación con cy.task?

Aquí entra el mini-plugin dbQuery que se construyó en clases anteriores. A través de cy.task mandas una consulta SELECT directa a la base.

javascript cy.task('dbQuery', 'SELECT * FROM employees WHERE id = 3') .then((results) => { cy.log(results) expect(results.length).to.equal(0) })

Si el registro fue eliminado de verdad, results.length debe ser cero. Y aquí viene lo interesante: si pruebas con un ID que aún existe, por ejemplo el 2, el test falla porque la base sí devuelve datos. Esa falla es justamente la señal de que tu prueba está midiendo lo correcto.

¿Qué hace cy.task en Cypress? Ejecuta código Node.js fuera del navegador, lo que te permite correr consultas SQL u operaciones que no son posibles desde el contexto del browser.

¿Cómo evitar IDs hardcodeados entre pruebas?

Dejar el número 3 escrito en cada bloque es frágil. La práctica recomendada es guardar el ID en un alias del contexto de Cypress y reutilizarlo con interpolación de strings.

Un esquema más robusto se vería así:

• Creas el registro en la base y obtienes su ID.
• Guardas ese ID con un alias para pasarlo entre los it.
• Lo inyectas tanto en la URL del cy.request como en la consulta SQL del cy.task.

javascript cy.request({ url: employees/${id}, method: 'DELETE' })

De esta forma, el mismo ID viaja por toda la prueba sin que tengas que tocarlo manualmente. Cambias el dato en un solo lugar y todo el flujo sigue funcionando.

¿Qué retos puedes resolver con este patrón?

El patrón que combina cy.request con cy.task es el corazón de las pruebas de integración entre capas. Sirve igual para validar creaciones, actualizaciones o eliminaciones, y se adapta tanto a bases relacionales como no relacionales.

Algunas extensiones que vale la pena explorar:

• Crear el registro desde la base, capturar el ID y validar que la API lo expone.
• Implementar el mismo ejemplo contra una base no relacional como MongoDB, ajustando el método del plugin.
• Encadenar varios endpoints en un mismo flujo, usando alias para mantener el estado.
• Validar formatos de respuesta, no solo existencia de datos.

La clave es pensar en escenarios reales: un checkout, un alta de usuario, una baja por GDPR. Cada uno toca varias capas y cada capa debe responder coherentemente.

¿Cuál es el escenario más complejo que se te ocurre para probar con este enfoque? Compártelo en los comentarios y cuéntanos qué parte del flujo te resulta más difícil de cubrir.