Es curioso, el significado del nombre de este lenguaje: “gherkin” comes from the Dutch word “gurken,” which means small pickled cucumber, pero tiene relación estrecha con el hecho de que fue creado por Cucumber: https://cucumber.io/docs/gherkin/reference/
Y, sin lugar a dudas, es la forma más clara para definir una situación y lo que se espera que suceda.
Gracias por el aporte, No tenia idea !
BDD (Behavior Driven Development) (Desarrollo dirigido por comportamiento)
Es algo parecido al TDD (Test Driven Development) donde en ese tipo de desarrollo se escribe una prueba que falla y se desarrolla hasta que tenemos una prueba que va a pasar.
El BDD sigue un poco eso, sin embargo aqui vamos a describir por medio de oraciones y texto lo que queremos lograr o el comportamiento de nuestra aplicacion. Pero ¿cuales son los beneficios?, bueno, un beneficio puede ser que nos va a dar un lenguaje en comun entres los skateholders, scrum master, desarrolladores, QA, automatizadores etc. Todos vamos a saber que vamos a probar, que es lo que tenemos que desarrollar, que es lo que vamos a validar y que es lo que queremos pedir que se desarrolle en nuestra aplicacion.
GHERKIN
Es un lenguaje especifico para el BDD y es un lenguaje de dominio legible para empresas, pero en algunas empresas se le conoce como DCL. Fue creado por Cucumber.
Gherkin consta de un GIVEN (dado que) -WHEN (cuando) -THEN (luego)
Syntaxis Gherkin
Feature: Guess the word# The first example has two stepsScenario: Maker starts a gameWhen the Maker starts a game
Then the Maker waits for a Breaker to join
# The second example has three stepsScenario: Breaker joins a gameGiven the Maker has started a game with the word "silky"When the Breaker joins the Maker's game
Then the Breaker must guess a word with 5 characters
Feature
La caracteristica es un texto conciso, pero descriptivo de lo que se desea.
Se utiliza para describir una funcion de software y para agrupar diferentes escenarios.
Scenario
Un escenario es un ejemplo o ejemplos que ilustran alguna situacion empresarial determinable.
Consiste en una lista de pasos.
Los escenarios siguen el mismo patron:
Describe un contexto inicial.
Describe un evento.
Describe un resultado esperado.
Given
El proposito de los GIVEN es describir un estado del sistema conocido antes o precondiciones.
Ejemplos:
Describir el estado inicial de la base de datos.
Describir el estado inicial de un usuario (p. Ej: registrado)
When
El proposito de los WHEN es describir la accion clave que el usuario realiza que desencadena la transicion del estado.
Ejemplos:
Dar clic a un boton.
Hacer una peticion a un endpoint.
Then
El proposito de lo then es observar los resultados, estas observaciones tienen que estar relacionadas con el valor/beneficio en tu Feature.
Me gusta el BDD, porque es un lenguaje natural que todos entienden, evitando discrepancias entre Product Owners, Business Analysts y Devs
