¿Quieres compartir información entre dos pruebas de Cypress sin depender de funciones experimentales como cy.origin? Existe una alternativa estable usando plugins y tasks que funciona incluso si aún no migras a Cypress 10.

Esta técnica te sirve cuando trabajas con dominios distintos, manejas datos dinámicos entre escenarios o simplemente prefieres no arriesgarte con APIs experimentales. Vamos a ver el flujo paso a paso replicando un caso real de captura y reutilización de texto entre tests.

¿Cómo crear un plugin de Cypress dentro del archivo de configuración?

Aunque ya no existe el archivo de plugins como tal, puedes registrar tus tareas directamente en el archivo de configuración usando el evento on.

La idea es crear un objeto en memoria que actúe como almacén temporal y exponer dos tareas: una para guardar valores y otra para recuperarlos por key.

¿Qué estructura necesita el plugin?

El plugin requiere tres piezas mínimas para funcionar correctamente:

• Una constante tipo objeto declarada arriba, que servirá como contenedor de los valores.
• Una tarea guardar que reciba un valor, extraiga su key con Object.keys(valor)[0] y lo asigne al objeto contenedor.
• Una tarea obtener que reciba un key y devuelva el valor almacenado o null si no existe.

¿Por qué un task de Cypress debe retornar algo siempre? Porque si no retornas un valor, Cypress lanza un error y detiene la ejecución. Cuando no necesites devolver nada útil, retorna null explícitamente.

Este detalle es de los que más confunden al principio [02:15], así que tenlo presente cada vez que escribas una tarea nueva.

¿Cómo usar cy.task para compartir datos entre dos tests?

La lógica es sencilla: en el primer test capturas el dato y lo guardas con cy.task; en el segundo test lo recuperas y lo inyectas donde lo necesites.

En el ejemplo, el primer test visita una página, obtiene el h1 con cy.get, toma el primer elemento y extrae su texto con .invoke('text'). Dentro del .then, ese texto se envía al plugin:

javascript cy.task('guardar', { texto: text })

El segundo test visita otra página y recupera el valor con la tarea obtener, pasándole el key texto. Luego lo escribe en un campo del formulario usando .type().

javascript cy.task('obtener', 'texto').then((valor) => { cy.get('#title').type(valor) })

¿Por qué usar dos tests separados en lugar de uno solo?

Sin cy.origin, Cypress no permite visitar dos dominios distintos dentro del mismo test. Pero sí puedes visitar dominios diferentes en tests separados dentro del mismo archivo.

Ahí es donde el plugin brilla: te da un puente de información que sobrevive entre ejecuciones de tests, algo que las variables normales de JavaScript no garantizan en el mismo nivel de control.

¿Cuándo conviene usar task en vez de cy.origin? Cuando aún trabajas con versiones previas a Cypress 10, cuando no quieres depender de flags experimentales, o cuando solo necesitas compartir datos puntuales entre escenarios.

¿Qué resultado obtienes al ejecutar las pruebas?

Al correr el spec, Cypress ejecuta el primer test, captura el texto (en el ejemplo, Bulbasaur), lo guarda en el objeto del plugin y termina.

Luego arranca el segundo test, visita la nueva página, llama al task obtener, recibe Bulbasaur y lo escribe en el campo correspondiente. Todo sin tocar cy.origin ni configuraciones experimentales.

Esta es la misma lógica que ya viste con variables de entorno, pero más limpia porque mantiene el estado encapsulado en tu configuración y no contamina el entorno global.

¿Qué casos no resuelve esta técnica?

Aún queda un escenario común sin resolver: cuando das clic en un botón y este abre un link en una pestaña nueva del navegador.

Cypress no tiene una función nativa para cambiar de pestaña, a diferencia de Puppeteer o Selenium, que sí ofrecen ese control. Para esos casos necesitas estrategias específicas que veremos más adelante.

¿Has tenido que compartir datos entre tests en tus proyectos? Cuéntame en los comentarios qué método usas y qué problemas has enfrentado.