Logo Studenta

Investigación - Lenguaje Gherkin

¡Este material tiene más páginas!

Vista previa del material en texto

¿Qué es Gherkin?
Gherkin es un Lenguaje Específico de Dominio (DSL), que son lenguajes diseñados en concreto para resolver un problema muy específico. Y, en este caso, el problema que quiere solucionar Gherkin es un problema de comunicación entre los perfiles de negocio y los perfiles técnicos a la hora de trabajar bajo un enfoque BDD. Gherkin está compuesto por varios elementos que permiten esta comunicación entre perfiles de negocio y técnicos de forma sencilla.
Vamos a verlo con un ejemplo. Pongamos que estamos desarrollando una tienda online o ecommerce. Partamos de historias de usuario, de dónde obtendremos las funcionalidades, siguiendo el clásico modelo de “Yo como usuario quiero poder hacer x para poder obtener y”. En este caso de desarrollo de una tienda online, podríamos estar ante la siguiente funcionalidad: “Yo como usuario quiero poder iniciar sesión para poder comprar productos”.
Ahora traduzcamos esto a Gherkin y expliquemos qué es cada elemento del lenguaje (puedes consultar las definiciones en el siguiente apartado):
Feature: inicio de sesión en la tienda online.
Scenario: inicio de sesión mediante usuario y contraseña.
Given: el usuario ha de introducir de forma correcta su usuario y su contraseña, que ha registrado previamente. 
When: el usuario clica sobre el botón de iniciar sesión.
Then: el usuario puede iniciar sesión de forma correcta.
HERRAMIENTAS DE GHERKIN
¿Qué es?
Cucumber es una herramienta de testing BDD (Behavior Driven Development) que permite elaborar pruebas unitarias a partir de criterios de aceptación fácilmente entendibles por todos los intervinientes del proceso.
Las descripciones funcionales se escriben en este lenguaje y sirven simultáneamente como documentación de apoyo al desarrollo y las pruebas automatizadas. Cucumber es una herramienta que da soporte para aplicar la metodología de desarrollo BDD (Behavior Driven Development) y se basa en poner el foco desde el inicio en cómo el usuario interactúa con la aplicación.
¿Para qué sirve? 
Es utilizado para implementar metodologías como BDD y permite ejecutar funciones que han sido escritas en texto plano como pruebas de software automatizadas. Cucumber nació de la necesidad de unificar de forma legible documentación, pruebas de aceptación automatizadas y los requisitos de información.
A través de Cucumber, el analista puede definir un conjunto de casos de uso que permitan validar el desarrollo realizado. Cucumber utiliza el lenguaje Gherkin para especificar las pruebas, que es un lenguaje específico de dominio, legible por el área de negocio, que soporta más de 60 idiomas.
En resumen, Cucumber es una herramienta para automatizar pruebas que utiliza el lenguaje Gherkin para especificar las pruebas y permite elaborar pruebas unitarias a partir de criterios de aceptación fácilmente entendibles por todos los intervinientes del proceso. Además, es utilizado para implementar metodologías como BDD y se basa en poner el foco desde el inicio en cómo el usuario interactúa con la aplicación.
Los elementos de la herramienta Cucumber son:
Gherkin: Es un lenguaje de especificación que permite describir el comportamiento de un sistema en un formato legible por humanos Gherkin es el lenguaje utilizado por Cucumber para escribir los escenarios de pruebas.
Feature files: Son archivos de texto donde se escriben los criterios de aceptación en formato Gherkin. Estos criterios de aceptación se podrían ver como las pruebas que vamos a preparar
Step definitions: Son los fragmentos de código que se encargan de ejecutar los pasos definidos en los escenarios de Gherkin.
Objetos de página: Son una abstracción para la página web que se está verificando. Los objetos de página pueden ser utilizados tanto por JUnit como por Cucumber.
Specflow
Specflow es una herramienta que nos permite crear nuestras pruebas como una serie de pasos escritos de forma que sean entendidos por cualquier persona con Gherkin o BDD (Behavior Driven Development), el cual cuenta con las siguientes instrucciones principales:
Feature: Es una descripción a alto nivel para clasificar un grupo de escenario a probar.
Scenario: Un ejemplo concreto para probar una regla de negocios.
Given: Permite definir precondiciones para la prueba.
And: Un paso adicional para definir tus pruebas.
But: Otro paso adicional para tus pruebas.
When: Paso para definir la acción de prueba a ejecutar.
Then: Permite especificar la salida del paso anterior.
Un ejemplo sería el siguiente:
Después con una extensión de Visual Studio tecleamos el código para cada paso, donde podemos pasar variables o una tabla con los datos de tu prueba.
De esta forma puedes documentar tu sistema y a la vez ejecutar tus pruebas de forma automática.
¿Para qué sirve?
Principalmente sirve para las pruebas del tipo ATDD/BDD que aplican a la linea media de pruebas automatizadas (ver pirámide de pruebas automatizadas) que se utilizan a menudo como sinónimo de Especificación por Ejemplo(SBE). Esto nos permite pasar fácilmente de requerimiento a test y al mismo tiempo generar documentación con los tests.
Además de que se puede extender con Web Driver o alguna otra herramienta para pruebas UI para llevar a cabo las pruebas de la parte superior de la pirámide, con el beneficio de poder reusar escenarios.
SpecFlow sigue un patrón específico que depende de palabras clave que ayudan a describir la función cuyo comportamiento está definiendo. Las palabras clave se derivan de un lenguaje llamado Gherkin (igual que un tipo de pepinillo) y todo esto se origina en una herramienta llamada Cucumber (cukes.info). Algunas de estas palabras clave son Given, And, When y Then (Dado, Y, Cuando y Luego) y puede usarlas para crear un escenario. Por ejemplo, este es un escenario que está encapsulado en una función;
Agregar un nuevo cliente:
Puede ser un poco más específico, por ejemplo:
En esta última instrucción realizaré parte de la persistencia de datos. SpecFlow no se preocupa por la forma en que todo esto sucede. La meta consiste en escribir escenarios para demostrar si se alcanza el resultado y si este se mantiene. El escenario impulsará el conjunto de pruebas y las pruebas le ayudarán a configurar la lógica del dominio:
¿Qué es Behat?
Para poder usar BDD en nuestros proyectos, y beneficiarnos de sus ventajas, usaremos Behat, que es la herramienta que nos permitirá realizar las pruebas sobre nuestro código. Behat nació con la idea de trasladar Cucumber al lenguaje PHP y, al igual que este, hace uso del lenguaje Gherkin para la escritura de los tests, así como de los ficheros con extensión
Veíamos antes que con BDD describimos el comportamiento que ha de realizar las funcionalidades de nuestra aplicación. Behat nos permite describir estos comportamientos con el lenguaje DSL Gherkin y dividirlos en distintos ficheros según la funcionalidad a comprobar. Lo mejor es ver un fichero de ejemplo donde podáis ver la estructura, comprobaréis que al comienzo, definimos la funcionalidad, y cada uno de los criterios de aceptación vienen contemplados en los escenarios:
 
DOCUMENTACIÓN DE BEHAT
Behat es un marco de desarrollo impulsado por el comportamiento de código abierto para PHP 5.3+.
 ¿Qué es el desarrollo impulsado por el comportamiento, te preguntarás? 
Es una forma de desarrollar software a través de una comunicación constante con las partes interesadas en forma de ejemplos; ejemplos de cómo este software debería ayudarlos a ellos y a usted a lograr sus objetivos. (Behat, 2016)
Por ejemplo, imagine que está a punto de crear el famoso comando ls de UNIX. Antes de comenzar, tendrá una conversación con las partes interesadas (usuarios de UNIX) y es posible que le digan que, aunque les gusta mucho UNIX, necesitan una forma de ver todos los archivos en el directorio de trabajo actual. Luego, tiene una conversación de ida y vuelta con ellos sobre cómo ven que funciona esta función y se le ocurre su primer escenario (un nombre alternativo, por ejemplo, en la metodología BDD):
Si usted es una parte interesada,esta es su prueba de que los desarrolladores entienden exactamente cómo desea que funcione esta característica. Si es un desarrollador, esta es su prueba de que la parte interesada espera que implemente esta característica exactamente de la manera en que planea implementarla.
Por lo tanto, como desarrollador, su trabajo finaliza tan pronto como haya ejecutado el comando 1s y haya hecho que se comporte como se describe en el escenario "Comando de listado".
Probablemente haya escuchado acerca de esta práctica de desarrollo moderna llamada TDD, donde escribe pruebas para su código antes, no después del código. Bueno, BDD es así, excepto que no es necesario que presente una prueba: sus escenarios son sus pruebas. ¡Eso es exactamente lo que hace Behat! Como verá, Behat es fácil de aprender, rápido de usar y le devolverá la diversión a sus pruebas. (My server, 2014)
Características de la herramienta:
Admite BDD para pruebas.
Se introduce en el lenguaje llamado Gherkin, que es legible para empresas.
Ayuda a eliminar detalles lógicos de la prueba de comportamiento.
Pros:
Es BDD y legible por humanos, por lo que si una persona que no conoce el lenguaje de programación también puede escribir las características fácilmente.
El mantenimiento de los casos de prueba es más fácil y comprensible.
Contras:
Para las pruebas de API, necesita pocas otras herramientas para admitirlo o integrarse con él.
El programador necesita comprender el lenguaje Gherkin.
Precios:
Como es una herramienta de código abierto, está disponible sin costo en el mercado para probadores y desarrolladores
¿Qué herramientas permiten lenguaje Gherkin?
Las herramientas Cucumber o JBehave, permiten implementación de una capa de conexión entre lenguaje Gherkin y la interfaz de usuario que se desea probar, pudiendo así utilizar eso como los pasos de una prueba automatizada.
Una de las principales características cuando hacemos BDD con Cucumber es que los escenarios de prueba a la funcionalidad se escriben mucho antes de la elaboración del código de una prueba automatizada. Cuando se escribe en lenguaje Gherkin sobre Cucumber se utilizan ejemplos concretos de lo que queremos que haga el software y a medida que se escriben los escenarios, estos asumen un papel importante como documentación del proyecto y documentación sobre las pruebas automatizadas.
Pasos para escribir lenguaje Gherkin con cucumber:
Crear un archivo con extensión “.feature” ejemplo “is_it_Friday_yet.feature”
Redactamos la HU con las palabras claves:
Feature: Search for an ítem
To check an item price and add them to shopping cart
as an online customer
user should be able to search for an ítem
Redactamos el/los escenarios asociados a esta HU con las palabras claves:
Scenario: Search products from navigation-menu
Given that Fray wants to buy Sweater
When He searches for Sweater using the navigation menú
Then He should see the list of Sweaters with prices available for sale
Para finalizar, con el uso del lenguaje gherkin se puede generar documentación de evidencia, hacer uso de este fragmento de código el cual puede ser implementado para realización de una prueba E2E o en una prueba unitaria, ya que podemos realizar el paso a paso de la prueba sobre esa historia de usuario con la ejecución de cada método o si solo se deseamos comprobar el resultado final de la prueba.
¿Cómo aplicar las reglas de negocio?
Las reglas comerciales guían el proceso de toma de decisiones del día a día de las empresas al mapear las relaciones entre los objetos, como los nombres de los clientes y los pedidos correspondientes. Esta traducción de las operaciones comerciales de una organización en una lógica comercial concreta permite a los ingenieros de software y analistas comerciales aplicar estas reglas para permitir la automatización de herramientas de flujo de trabajo u otros procesos. Sin ellos, los procesos de actualización pueden ser engorrosos y lentos, y los documentos están sujetos a más errores humanos e inconsistencias. Una empresa que implementa reglas comerciales puede ahorrar tiempo y dinero al optimizar el trabajo y reducir el rechazo.
Reglas de negocio frente a requisitos de negocio
Algunas personas pueden confundir los términos reglas de negocio y requisitos de negocio, pero en realidad son muy distintos. Por ello, conviene señalar cómo se utilizan dentro de los entornos empresariales.
Las reglas de negocio proporcionan la base para los sistemas de automatización: recopilan información documentada o no documentada y la traducen en distintas declaraciones condicionales. Por ejemplo, al realizar una orden de compra, el proceso de aprobación puede diferir en función del coste. Los requisitos de negocio establecen los criterios de éxito para un proyecto determinado. Al especificar las tareas y los recursos necesarios para completar el proyecto, los equipos pueden ver más claramente las carencias y las barreras que le impiden lograr su objetivo.
Dentro de estos procesos, existen reglas que deben seguirse durante la ejecución de las actividades, que ayudan a definir CÓMO deben realizarse y gestionarse las operaciones, por QUIÉN, CUÁNDO, DÓNDE y POR QUÉ, según la definición del BPM CBOK.
Podemos decir que las reglas de negocio son límites impuestos a las operaciones, para que estén correctamente en sintonía con las políticas y objetivos de la institución. En general, las reglas de negocio deben:
Tener una sola función, ser indivisibles y simples.
Ser completas, con un principio, un desarrollo y un final.
Ser posibles de medir y rastrear.
Estar en consonancia con la legislación.
Estar al día y en constante revisión.
Reflejar la política y los valores de la organización.
Ser inteligibles para los empleados y los que participan en el proceso.
Cómo aplicar las reglas de negocio
Entender lo qué son las reglas de negocio es el primer paso.
Ahora, hay que saber cómo funcionan.
Muy asociadas al buen rendimiento de los procesos y estrategias de una empresa, los gestores deben definir esas reglas mediante un excelente análisis de sus procesos.
Dichas reglas deben estar de acuerdo con las políticas de la empresa, dialogar con sus objetivos y fortalecer las estrategias definidas.
Por lo tanto, una sugerencia importante es tratar de considerar las posibles reglas en el momento en que se está implementando una planificación estratégica, para hacer posible que se logren las metas de la forma más acertada.
Para aplicar las reglas de negocio es cada vez más común el uso de la tecnología, lo que garantiza procesos automatizados, más ágiles y eficientes. 
Bibliografía
(s.f.). Obtenido de Crehana: https://www.crehana.com/blog/negocios/que-son-reglas-negocio/
Chakray. (s.f.). Obtenido de https://www.chakray.com/es/testing-cucumber-afianzar-fiabilidad-desarrollos/
García, R. S. (24 de Diciembre de 2020). Obtenido de https://elminimoviable.es/que-es-cucumber-y-como-agilizar-el-testing/
Gitbook. (s.f.). Obtenido de https://abi.gitbook.io/net-core/10.-pruebas-de-integracion/10.1-que-es-specflow
HEFLO. (s.f.). Obtenido de https://www.heflo.com/es/blog/automatizacion-procesos/que-son-reglas-negocio/
Hernandez, R. (9 de Noviembre de 2018). Obtenido de https://www.genbeta.com/desarrollo/bdd-cucumber-y-gherkin-desarrollo-dirigido-por-comportamiento
IBM. (s.f.). Obtenido de https://www.ibm.com/es-es/topics/business-rules
Microsoft. (s.f.). Obtenido de https://learn.microsoft.com/es-es/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow

Continuar navegando