Behavior Driven Development
BDD se define en un idioma común entre todos los stakeholders (interesados), lo que mejora la comunicación entre equipos tecnológicos y no técnicos. En BDD las pruebas se centran en el usuario y el comportamiento del sistema.
La principal ventaja es que todas las definiciones BDD se escriben en un idioma común. El principal objetivo es que el equipo describa los detalles de cómo se debe comportar la aplicación a desarrollar, y de esta forma será comprensible por todos. Este acceso a una comunicación más clara y con la mínima jerga tecnológica, es probablemente la mayor ventaja del uso de BDD, lo que hace posible que la colaboración entre los equipos técnicos y no técnicos se ejecute con mayor eficiencia.
Given-When-Then como Lenguaje Común con BDD
Para definir los casos BDD para una historia de usuario se deben definir bajo el patrón ‘Given-When-Then’, que se define como:
Given ‘dado que’: Se especifica el escenario, las precondiciones.
When ‘cuando’: Las condiciones de las acciones que se van a ejecutar.
Then ‘entonces’: El resultado esperado, las validaciones a realizar.
Ejemplo
Dado que: El usuario no ha introducido ningún dato en el formulario.
Cuando: Hace clic en el botón Enviar.
Entonces: Se deben mostrar los mensajes de validación apropiados.
Role-Feature-Reason como Lenguaje Común con BDD
Este patrón también se utiliza en BDD para ayudar a la creación de historias de usuarios. Esta se define como:
As a ‘Como’: Se especifica el tipo de usuario.
I want ‘deseo’: Las necesidades que tiene.
So that ‘para que’: Las características para cumplir el objetivo.
Ejemplo
Como cliente interesado, deseo ponerme en contacto mediante el formulario, para que atiendan mis necesidades.
Ventajas de BDD (Behavior Driven Development)
- Ya no estás definiendo 'pruebas', sino que está definiendo 'comportamientos'.
- Mejora la comunicación entre desarrolladores, testers, usuarios y la dirección.
- Debido a que BDD sé específica utilizando un lenguaje simplificado y común, la curva de aprendizaje es mucho más corta que TDD (Test Driven Development).
- Como su naturaleza no es técnica, puede llegar a un público más amplio.
- El enfoque de definición ayuda a una aceptación común de las funcionalidades previamente al desarrollo.
- Esta estrategia encaja bien en las metodologías ágiles, ya que en ellas se especifican los requisitos como historias de usuario y de aceptación.
Herramienta de Definición BDD
La herramienta más destacada, basado en el patrón Given-When-Then es Cucumber, un framework de test con soporte BDD. En Cucumber, las especificaciones de BDD están escritas en lenguaje Gherkin, basado en Given-When-Then. En otras palabras, Gherkin presenta el comportamiento de la aplicación, a partir de la cual Cucumber puede generar los casos de prueba de la aplicación.
Para poder trabajar con las plantillas proporcionadas se debe instalar el plugin desde Eclipse Marketplace y todo archivo destinado a registrar las historia de usuario debe ser creado con la extensión .feature:
Plugin de Cucumbe:
Plantilla de historia de usuario:
Archivo con extensión .feature:
Descargar Archivo
Ejemplo de metodología BDD:
