Debuguear en Cypress es una habilidad clave cuando tu prueba no encuentra un elemento o falla sin razón aparente. Aquí descubrirás cinco formas prácticas de hacerlo, desde el clásico console.log hasta plugins personalizados, ideal para QA automation engineers y desarrolladores front que ya escriben pruebas end to end.

¿Cómo usar console.log y debugger en pruebas de Cypress?

El punto de partida casi siempre es el mismo: el console.log de toda la vida. Si quieres imprimir, por ejemplo, la longitud de un arreglo de inputs, agregas console.log('Soy la longitud', inputs.length) dentro de tu test y abres las DevTools del navegador para verlo.

Funciona, pero tiene un costo: necesitas tener la consola abierta y rebuscar entre los logs del runner.

La segunda opción nativa de JavaScript es la palabra clave debugger. Al colocarla en tu código, Cypress pausa la ejecución y te deja inspeccionar el call stack, los valores en memoria y avanzar línea por línea, igual que harías con React o cualquier framework de front.

¿Por qué mi debugger no se detiene en Cypress? Porque debugger solo se activa si tienes las DevTools abiertas. Si las cierras y corres la prueba, simplemente lo ignora.

¿Cómo crear un plugin de Cypress para imprimir logs en el servidor?

Cuando ejecutas tus pruebas en modo headless, dentro de un pipeline de CI o CD, no tienes navegador ni DevTools. Ahí es donde un plugin propio te salva, porque sí tendrás acceso al log del servidor de Cypress.

Dentro de la carpeta plugins/index.js, Cypress te expone una función on para enganchar eventos. Vas a registrar un task personalizado así:

js module.exports = (on, config) => { on('task', { log(message) { console.log('Soy el console log del task', message) return null } }) }

Luego, desde tu prueba, lo invocas con cy.task('log', inputs.length). Reinicia Cypress después de tocar el index.js para que tome los cambios. En el ejemplo de la clase, el task imprime una longitud de 15 directamente en la terminal donde corre el servidor.

Lo bueno: este mini plugin es extensible. Puedes hacer que ejecute operaciones, lea archivos o devuelva datos, no solo que imprima.

¿Qué diferencia hay entre cy.log, .then(console.log) y .debug en Cypress?

Cypress también ofrece atajos pensados para que no tengas que abrir nada. El primero es encadenar un .then(console.log) después de obtener un elemento. Eso imprime el objeto completo con sus valores y funciones en la consola del navegador.

El segundo es cy.log, y es el que más comodidad te da en el día a día. En vez de mandar al console del navegador, imprime el mensaje dentro del propio runner de Cypress, en el panel de comandos a la izquierda. Lo ves sin abrir DevTools.

El tercero es .debug(), una utilidad nativa que aplicas sobre un comando. Cuando abres la consola, te muestra de forma estructurada qué comando se ejecutó y qué retornó, lo que resulta más claro que un console.log plano.

¿Cuándo conviene usar cy.log en vez de console.log? Cuando quieres ver el valor directamente en el runner de Cypress sin abrir DevTools, especialmente al revisar pruebas que ya pasaron paso a paso.

¿Para qué sirve cy.pause en una prueba?

Este es uno de los comandos más útiles cuando tu prueba va demasiado rápido para entender qué falló. cy.pause() detiene la ejecución en ese punto y te muestra controles para reanudar o saltar al siguiente pause del test.

Es ideal para confirmar si la página cargó, si un selector existe en ese momento o si el estado del DOM es el esperado antes de continuar.

¿Cuál técnica de debugging de Cypress deberías elegir?

No hay una respuesta única, depende del contexto en el que estés trabajando:

• console.log: rápido y universal, pero exige DevTools abiertas.
• debugger: potente para inspección paso a paso, también requiere consola abierta.
• cy.task con plugin propio: imprescindible para modo headless en CI o CD.
• cy.log: cómodo para ver mensajes dentro del runner sin salir de Cypress.
• .debug(): vista estructurada del comando y su retorno.
• cy.pause(): control manual cuando la prueba se ejecuta demasiado rápido.

Con estas herramientas combinadas vas a poder rastrear por qué un selector no aparece, por qué una aserción no se cumple o por qué una página no termina de cargar, sin importar si trabajas localmente o en una integración continua.

¿Cuál de estas técnicas usas más en tus pruebas y en qué escenario te ha sacado del apuro? Cuéntame en los comentarios.