Propósito y beneficios de usar BDD
- En lo más profundo, BDD se trata de tener conversaciones para ayudar a los equipos a superar los requisitos mal interpretados y problemas de entrega
- Las ideas y conceptos se comparten discutiendo ejemplos concretos de la vida real de los requisitos y comportamientos del producto
- BDD permite que las partes interesadas, clientes, devs, hablen en un idioma común (Gherkin) sobre la entrega.
- BDD valora la colaboración por encima de los documentos de requisitos que normalmente se pueden mal interpretar
- BDD permite creación de documentación para la solución técnica.
Por qué SHIFT LEFT
Básicamente se trata de mover las actividades de testing más hacia la izquierda del proceso de desarrollo. La idea es anticipar y tener en cuenta el testing desde el principio.
Ventaja 1. Las pruebas se hacen antes, por lo que el feedback se obtiene antes, los potenciales problemas se descubren y se pueden resolver antes mejorando así la calidad del producto final.
ventaja 2. Seguramente este hecho apoye a que se desarrollen componentes testeables, más fáciles de probar y de automatizar. Esto aporta un gran valor.
ventaja 3. Sharing is caring y se ha comprobado que cuando se testea solo se tiene menos cuidado, a diferencia de compartir las tareas fomentando la colaboración el éxito es mayor.
3 prácticas a aplicar
- Descubre a través de la colaboración
- Formulación (Documentación)
- Automatización de la documentación
Términos clave
Gherkin tiene 3 componentes clave: Feature, Scenario & Steps (GWT)
Feature (Elemento de alto nivel)
Es la descripción de la funcionalidad a desarrollar.
Scenario (Elemento de tipo comportamiento)
Una feature tiene uno o varios scenarios, que son distintas características que se tienen que desarrollar para poder conseguir lo que nos hemos propuesto entregar.
Steps (GWT) (Elementos de tipo acción)
Given: Precondiciones para que se puedan ejecutar x acciones. Tu puedes tener varios "And" si se necesita para acumular acciones.
When: Condiciones de las acciones que se van a ejecutar.
Then: Resultado esperado de las acciones ejecutadas.
Ejemplo
Feature: Inicio de sesión en udemy
Scenario: Inicio de sesión con usuario y password
Given: El usuario tiene que introducir de manera correcta el usuario y password, que ha registrado con anterioridad.
When: El usuario hace click en "iniciar sesión"
Then: El usuario inicia sesión de manera correcta.
Gherkin
Feature > User Story > Gherkin Feature > Scenario(s) > G.Steps
BDD Feature Best Practices
Empieza con una persona. Recuerda que un cliente no es necesariamente un comprador.
Escribir "Declarative features"; Describir como si lo hiciera un usuario, de manera muy humana.
Insertar una narración; Describen en una oración lo que hace una feature. Las narrativas son importantes para imaginar por qué está implementando una función en primer lugar
Escribe la feature con la intención de cambiar el comportamiento del cliente. Afectará al patrón de prueba.
BDD se centra en featureFiles no en story files.
Las features deben de ser independientes entre si y proporcionar un cambio de comportamiento de la funcionalidad.
Use Story Mapping cuando una característica constituya un flujo de trabajo.
Features
Todas las Gherkin features son independientes unas de otras.
Cada feature o scenario deben ser ejecutadas independientemente.
Todos los steps deben tener info independiente (y sin son steps entre 50 - 80 caracteres mucho mejor).
Cucumber
La mejor forma de usar Gherkin es con Cucumber, un framework de testing con soporte para BDD, dónde las especificaciones BDD están escritas de acuerdo al patrón “Given-When-Then”. (Osease, en Gherkin)
Cucumber, puede generarnos los casos de prueba de la aplicación y darnos una mayor velocidad en el desarrollo del software
Este verifica que el software cumpla con la especificación y genera un informe que indica ✅ éxito o ❌ falla para cada scenario.
Este es un primer contacto de lo que BDD puede ofrecer y parece muy poderoso. Veremos en los próximos pasos :)
Top comments (0)