Si trabajas con Cypress y Cucumber, llega un punto donde repetir el mismo escenario con distintos datos se vuelve insostenible. Aquí entra el scenario outline, una herramienta de Gherkin que convierte tus pruebas en data driven tests, ejecutando el mismo flujo con múltiples combinaciones de datos sin duplicar código.

Qué es un scenario outline y cuándo conviene usarlo

Un scenario outline es un escenario plantilla que se ejecuta una vez por cada fila de datos definida en una sección de examples. En lugar de escribir cuatro veces el mismo login con distintos usuarios, escribes el flujo una sola vez y dejas que la tabla haga el trabajo.

La estructura tiene tres piezas que conviene tener claras desde el inicio [01:30]:

• La palabra clave Scenario Outline antes del nombre del escenario.
• Parámetros entre signos de menor y mayor que, por ejemplo <user> y <pass>.
• Una tabla Examples con las columnas que coinciden con esos parámetros.

Cada fila de la tabla genera una corrida independiente. Si tienes cuatro filas con username y password distintos, Cucumber ejecuta cuatro escenarios completos, uno por combinación.

¿Qué es un scenario outline? Es una plantilla de escenario en Gherkin que se ejecuta una vez por cada fila de la tabla Examples, permitiendo probar el mismo flujo con datos distintos sin repetir código.

Cómo reutilizar step definitions con expresiones regulares

Uno de los puntos finos al pasar de un scenario normal a un scenario outline es ajustar los step definitions para que acepten ambos formatos: valores entre comillas y valores entre signos de mayor y menor que [03:45].

Cuando WebStorm autogenera el step a partir de un outline, la expresión regular cambia ligeramente para tolerar los dos casos. Eso te permite reutilizar el mismo paso de login sin importar si lo invocas con "usuario1" o con <user>. El truco está en quitar las comillas del feature y dejar que el parámetro fluya directo desde la tabla.

Validar estados compartidos entre escenarios

Pasos como validar que el usuario no quedó logueado conviene definirlos en el archivo de login original y no dentro del outline. La razón es práctica: esa validación aplica tanto al login normal como al outline, así que centralizarla evita duplicar lógica.

Dentro del page object LoginPage puedes apoyarte en un método tipo validateErrorLogin() para confirmar que la sesión no se inició cuando las credenciales son inválidas.

Cómo filtrar pruebas con tags en Cucumber y Cypress

Correr toda la suite cada vez que cambias algo es lento. Los tags de Gherkin resuelven esto permitiéndote ejecutar solo los escenarios marcados con una etiqueta específica [07:20].

El flujo es directo:

1. Agrega un tag como @probando arriba del escenario o feature que quieres aislar.
2. Define en package.json un script que use la variable de entorno tags, por ejemplo cucumber-tags.
3. Ejecuta ese script y Cypress correrá solo lo que coincida con el tag.

Los escenarios sin el tag aparecen como pending en la salida de la terminal, no como fallidos. Es decir, Cucumber los reconoce pero los salta intencionalmente.

¿Para qué sirven los tags en Gherkin? Sirven para filtrar qué escenarios se ejecutan. Marcas pruebas con @tag y corres solo las que coincidan, útil para separar por ambiente, prioridad o feature.

Ejecutar Cypress en modo headless

El comando npx cypress run lanza la ejecución sin abrir la interfaz gráfica, ideal para integraciones continuas o para validar rápido desde la terminal. Combinado con tags, te da control fino sobre qué corre y qué no en cada ejecución.

Diferencia entre scenario outline y data tables

Ambos sirven para pasar datos a tus pasos, pero funcionan distinto. El scenario outline ejecuta un escenario completo por cada fila de examples. Las data tables, en cambio, pasan una tabla como argumento dentro de un solo paso, sin multiplicar la ejecución [11:50].

Usa scenario outline cuando quieras correr el mismo flujo varias veces con datos distintos. Usa data tables cuando solo necesites entregar un conjunto de datos a un paso específico dentro de un único escenario.

Esta distinción importa porque define cuántas veces se ejecuta tu prueba y cómo se reportan los resultados. Cuéntanos en los comentarios cómo te fue implementando data tables en tu propio proyecto.