Implementación de Esquemas de Escenarios de Cucumber en Frameworks BDD
El desarrollo guiado por el comportamiento (BDD, por sus siglas en inglés) es una práctica ágil de desarrollo de software que mejora la colaboración entre los interesados y los desarrolladores, utilizando un lenguaje simple y específico del dominio para describir el comportamiento del sistema.
Una de las herramientas más potentes en BDD es Cucumber, que se utiliza para escribir especificaciones claras. También puede emplearse en pruebas, en la mayoría de los lenguajes de programación más usados, como Java, Python o C#, y puede integrarse con frameworks de interfaz de usuario, como Selenium, o usarse para pruebas de API.
Los esquemas de escenario forman parte de la sintaxis Gherkin de Cucumber, utilizada para escribir especificaciones ejecutables. A diferencia de los escenarios normales, que definen un ejemplo concreto, los esquemas de escenario permiten especificar varios ejemplos en formato tabular.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Diferencias entre escenario y esquemas de escenario
Los escenarios en Cucumber representan un caso de prueba escrito en la forma básica de dado-cuando-entonces. El lenguaje Gherkin permite que estos escenarios de prueba se escriban en inglés simple (y en otros idiomas), para que sean fácilmente comprensibles e incluso puedan ser redactados por personas no técnicas. Las definiciones de los pasos, que representan la implementación de estos pasos, se crean en archivos separados.
Para algunas funcionalidades, tiene sentido repetir el mismo escenario usando diferentes datos de prueba: esto probablemente lo conoces como pruebas basadas en datos. En Cucumber, esto se realiza utilizando el esquema de escenario con una tabla de ejemplos que contiene los conjuntos de datos a utilizar. Cada ejemplo se cuenta como una prueba distinta.
Sintaxis del Esquema de Escenario de Cucumber
Un proyecto típico de Cucumber contiene archivos de características, donde se definen las pruebas de Cucumber, y archivos de definición de pasos, donde están las implementaciones de los pasos.
Un archivo de características debe representar la especificación de un requerimiento y los escenarios utilizados para probarlo. La sintaxis básica para un escenario simple de Cucumber es la siguiente:
Escenario: Inicio de sesión inválido
Dado que navego a la página de inicio de sesión
Cuando ingreso credenciales inválidas
Entonces recibo un mensaje de error
El escenario también puede contener variables, que serán tratadas como tales en la definición de los pasos.
Escenario: Inicio de sesión inválido
Dado que navego a la página de inicio de sesión
Cuando ingreso el usuario test y la contraseña invalid
Entonces recibo un mensaje de error: "Inicio de sesión inválido".
Los valores “test”, “invalid” e “Inicio de sesión inválido” serán tratados como variables. Ahora veamos qué pasa si queremos probar diferentes combinaciones de las variables proporcionadas: podríamos terminar con múltiples escenarios idénticos excepto por los valores de las variables, o usar el esquema de escenario, que nos permite utilizar una tabla donde definimos las diferentes combinaciones de datos:
Entonces recibo un mensaje de error: "<mensaje de error>".
Ejemplos:
| usuario | contraseña | mensaje de error |
| test | invalid | Inicio de sesión inválido |
| test | | Por favor, ingrese la contraseña |
| | invalid | Por favor, ingrese el nombre de usuario |
La combinación de datos se escribe bajo la palabra clave “Ejemplos”, dentro de una tabla. Los encabezados de las tablas son los nombres de las variables, y cada fila representa una combinación de datos. Cada ejemplo dentro de una característica de Cucumber se tratará como un caso de prueba individual.
Tabla de Ejemplos vs Tablas de Datos
Las tablas de ejemplos y las tablas de datos pueden parecer similares, pero cumplen diferentes propósitos. La principal diferencia es que los ejemplos se utilizan para implementar escenarios orientados a datos, mientras que las tablas de datos se usan cuando los pasos del escenario necesitan usar múltiples variables.
Una tabla de datos puede usarse así:
Escenario: Inicio de sesión inválido
Dado que navego a la página de inicio de sesión
Cuando ingreso las credenciales
| usuario | contraseña |
| test | invalid |
Entonces recibo un mensaje de error: "Inicio de sesión inválido".
o así:
Escenario: Inicio de sesión no válido
Dado que navego a la página de inicio de sesión
Cuando ingreso las credenciales
| usuario | test |
| contraseña | invalid |
Entonces recibo un mensaje de error: "Inicio de sesión no válido".
Las tablas de datos son especialmente útiles cuando los pasos requieren múltiples variables, y son más fáciles de leer que cuando cada valor se escribe dentro del paso.
Trabajando con Tablas de Datos y Escenario Esquema
Las tablas de datos y los esquemas de escenario también pueden funcionar juntos. El nombre de la variable se proporciona dentro de la tabla de datos y luego se reutiliza en la tabla de ejemplos.
Esquema de escenario: Inicio de sesión no válido
Dado que navego a la página de inicio de sesión
Cuando ingreso las credenciales
| usuario | <username> |
| contraseña | <password> |
Entonces recibo un mensaje de error: "<mensaje de error>".
Ejemplos:
| usuario | contraseña | mensaje de error |
| test | invalid | Inicio de sesión no válido |
| test | | Por favor ingrese la contraseña |
| | invalid | Por favor ingrese el nombre de usuario |
Ventajas de utilizar escenarios esquema
Los esquemas de escenario pueden interpretarse como una “plantilla” de un caso de prueba. Lo que realmente hacen, una vez implementados dentro de un marco de automatización de pruebas, es ejecutar el mismo escenario con diferentes conjuntos de datos.
La ventaja es que hay menos líneas de Gherkin y menos repetición. Esto significa que cada vez que se necesite un cambio en el escenario común, solo será necesario cambiarlo una vez y el cambio se aplicará a todas las combinaciones de datos de prueba.
Otra ventaja de los esquemas de escenario es que pueden proporcionar mayor cobertura con un esfuerzo mínimo. Para agregar una nueva prueba, solo necesitas añadir una nueva línea de ejemplo.
Mejores prácticas para escribir esquemas de escenario
- Incorpora datos reales: El equipo tiene menos probabilidades de pasar por alto casos límite o información oculta cuando emplea casos de uso en tiempo real para comprender el comportamiento.
- Comunica el objetivo utilizando la terminología del negocio para ayudar a que las partes interesadas técnicas y no técnicas del equipo se entiendan mejor.
- Explica tu intención en lugar de cómo se implementará; las explicaciones de los pasos deben ser mínimamente técnicas. Deben centrarse más en las funciones del sistema que en su operación.
- Conserva solo lo necesario: Para mantener el escenario interesante para todos los participantes, no lo sobrecargues con pasos innecesarios.
Conclusiones
Mejora de la Colaboración: BDD mejora la colaboración entre las partes interesadas y desarrolladores.
Lenguaje Sencillo: BDD utiliza un lenguaje simple y específico del dominio para describir el comportamiento del sistema.
Práctica Ágil: BDD es una práctica dentro del desarrollo ágil de software.
Participación de los Interesados: BDD involucra a las partes interesadas en la definición del comportamiento del sistema.
Descripción del Comportamiento del Sistema: BDD se centra en describir de manera efectiva el comportamiento del sistema.
Cucumber es una gran herramienta de colaboración entre personas no técnicas, desarrolladores y testers. Es una herramienta BDD que proporciona especificaciones escritas y puede utilizarse en pruebas. Se pueden escribir múltiples escenarios para demostrar varios requisitos.
Es recomendable usar esquemas de escenarios con conjuntos de valores diferentes proporcionados a través de la tabla de ejemplos cuando existan situaciones en que los escenarios tienen los mismos pasos pero requieren diferentes valores de datos como entradas o salidas.
Suscríbete al boletín de The CTO Club para más información.
