A quien no conozca Gherkin, le podemos decir que es uno de los estándar para realizar pruebas escritas con un lenguaje muy sencillo y fácil de entender. Está basado en técnicas de BDD y se agrupa en:
• Estado inicial: Nos preguntamos ¿Dónde?
• Acción: Nos preguntamos ¿Cuándo?
• Resultado esperado: Nos preguntamos ¿Entonces?
Toda esta información está agrupada en Escenarios. Este es un paso muy rápido sobre de que trata este lenguaje, de cara a hacerse una idea de lo que podemos llegar a hacer con él.
Cucumber, como herramienta, que está basada en Gherkin, tiene una muy buena perspectiva en una serie de situaciones, donde su utilización está más que recomendada:
• Al dar de alta nuevas historias de usuario y sus criterios de aceptación, si utilizamos este tipo de lenguaje, podemos acordar con producto y desarrollo una serie de escenarios que sean válidos, completos y automatizables en un siguiente paso.
• En algunas ocasiones, este tipo de lenguaje nos hará entender los motivos comerciales por los cuales se va a realizar o se ha realizado una funcionalidad en concreto. Es algo muy sencillo de entender, de llevar a la práctica y de trabajar para todos los perfiles que estén involucrados en el proyecto.
• Es una manera muy sencilla de trazar los requisitos al código y a su vez a las pruebas realizadas, por lo tanto, podemos decir que estamos trabajando bajo una documentación viva que está actualizada en todo momento.
En ocasiones, tenemos que enfocar nuestras pruebas en el API y si ya tenemos Cucumber o alguna herramienta basada en Gherkin funcionando, que mejor que utilizarla para ello, algo que no es del todo recomendable.
Al realizar una prueba en el API, habitualmente llamamos a una URL y bajo una serie de parámetros, esperamos un resultado esperado positivo o negativo. En gran medida, no es de vital importancia como lleguemos a llamar a esa URL con esos parámetros, para ello hay herramientas como Postman que nos pueden ayudar a ello, pero en este caso, nos enfocamos en Gherkin.
En el caso de este tipo de pruebas, no es necesaria la filosofía de Gherkin con ese lenguaje natural ya que no aplica en la llamada a una URL que nos aporta un resultado. Si lo pensamos fríamente, no es relevante el manejar las preguntas expuestas más arriba para saber el resultado de una prueba de este tipo.
Cuando realizamos pruebas en un API, podemos tener dos objetivos principales, uno es la cobertura y otro es la funcionalidad (cosa que no debería de ser una prueba en un API).
Si por ejemplo, mandamos un dato vacio a un campo obligatorio, esperaremos un error que nos diga que hay que rellenar el campo, por lo tanto, no es necesario la realización de las preguntas: donde, cuando y entonces que usaremos en Gherkin.
Si estamos utilizando BDD para realizar nuestras pruebas, no solemos enfocarnos en una tecnología en concreto, si no más bien en la funcionalidad. Veamos algunos problemas típicos que podemos encontrarnos:
• Si nos enfocamos en tecnología, esta puede cambiar a menudo, cosa que nos romperá las pruebas. Pero si nos enfocamos en la funcionalidad, las pruebas, seguramente no cambien con tanta frecuencia y el mantenimiento será menor.
• Al escribir pruebas con Gherkin, solemos tratar el lenguaje de una manera demasiado prosaica, cosa que hace que sea accesible para todos, pero pierde el punto técnico, por lo tanto, debemos de enfocarnos a crear un tipo de lenguaje que ayude a que los desarrolladores entiendan las razones comerciales o de negocio de la funcionalidad que van a desarrollar.
• En relación a las pruebas unitarias, las pruebas basadas en Gherkin, son más complejas de cerrar, ya que suelen llevar el estado entre métodos con variables, los IDE tienen una capacidad menor de depuración y en algunas ocasiones el trasladar ese lenguaje sencillo a código, es un poco complicado (a veces, juega en contra el como se entiende la frase en concreto).
Por último, diremos que Gherkin es un marco BDD integral, por lo que se debe de utilizar siempre en entornos de este tipo. En el caso de las pruebas API que hablábamos anteriormente, no tiene sentido que se realicen con este lenguaje, ya que se deben de orientar más a la solución técnica, en comparación con que al realizar BDD de este modo, nos enfocaremos más en funcionalidades de negocio.
Esperamos que os hayamos ayudado a tener una idea más clara de donde utilizar Gherkin y donde no para que sea realmente eficiente y su uso sea el adecuado, sin complicaros la vida en traducciones de lenguaje complejas a código y no invertir más tiempo de lo habitual.
0 Comentarios