BDD (Behavior Driven Development), es una estrategia de desarrollo dirigido por comportamiento, que ha evolucionado desde TDD (Test Driven Development), aunque no se trata de una técnica de testing.
A diferencia de TDD, BDD se define en un idioma común entre todos los stakeholders, lo que mejora la comunicación entre equipos tecnológicos y no técnicos. Tanto en TDD como en BDD, las pruebas se deben definir antes del desarrollo, aunque en BDD, las pruebas se centran en el usuario y el comportamiento del sistema, a diferencia del TDD que se centra en funcionalidades.
En Behavior Driven Development (BDD), las pruebas de aceptación proporcionan el punto de partida para el flujo de diseño de software y sirven como base para la comunicación entre diseñadores y partes interesadas. En esta técnica de desarrollo de software ágil, las pruebas de aceptación se escriben en lenguaje natural para garantizar una comprensión común entre todos los miembros del proyecto. Como consecuencia, mapear las oraciones al código fuente real es el primer paso del flujo de diseño, que generalmente se realiza manualmente.
Sin embargo, los escenarios descritos por las pruebas de aceptación proporcionan suficiente información para automatizar la extracción tanto de la estructura de la implementación como de los casos de prueba. En este trabajo, proponemos un flujo asistido para BDD donde el usuario entra en un diálogo con la computadora que sugiere fragmentos de código extraídos de las oraciones. Para este propósito, se explotan las técnicas de procesamiento del lenguaje natural. Esto permite una transformación semiautomática de las pruebas de aceptación a los apéndices del código fuente y, por lo tanto, proporciona un primer paso hacia la automatización de BDD.
A diferencia de BDD, TDD funciona apropiadamente siempre que la dirección de la organización esté familiarizada con estas pruebas unitarias, en definitiva que sus habilidades técnicas sean lo suficientemente sólidas, y no siempre es así.
En estas circunstancias, la BDD tiene la ventaja de que las pruebas unitarias se pueden escribir en un lenguaje común utilizado por todas las partes interesadas. 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.
BDD ofrece una guía más precisa para organizar la conversación entre desarrolladores, evaluadores y expertos en dominios.
Las anotaciones que se originan en el enfoque de BDD, en particular el lienzo dado cuando entonces , están más cerca del lenguaje cotidiano y tienen una curva de aprendizaje más superficial en comparación con las de herramientas como Fit / FitNesse
Las herramientas dirigidas a un enfoque BDD generalmente permiten la generación automática de documentación técnica y de usuario final a partir de las "especificaciones" BDD
En este trabajo, propusimos un flujo asistido para BDD donde el usuario entra en un diálogo
con la computadora para generar semiautomáticamente definiciones de pasos y esqueletos de códigos a partir de un escenario dado. Para ello, herramientas de procesamiento del lenguaje natural.
Son explotados Un estudio de caso ilustró la aplicación. En lugar de pasar por el BDD establecido manualmente, el diseñador recibe automáticamente opciones que fácilmente se puede refinar.
El enfoque propuesto es un paso significativo hacia una automatización de BDD. Además, si bien el estudio de caso se centra en la prueba de aceptación dentro del esquema BDD. Los resultados del enfoque propuesto también motivan una consideración de la naturaleza general.
sistema de lenguaje específico.
Cada requisitos debe convertirse en historias de usuario, defiendo ejemplos concretos.
Cada ejemplo debe ser un escenario de un usuario en el sistema.
Ser consciente de la necesidad de definir "la especificación del comportamiento de un usuario" en lugar de "la prueba unitaria de una clase".
Comprender la fórmula ‘Given-When-Then’ u otras como las historias de usuario ‘Role-Feature-Reason'. Veamos que tratan estas fórmulas.
Herramientas de 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.
Hay muchas otras herramientas, tantas como lenguajes de programación:
Java: JBehave, JDave, Instinct, beanSpec
C: CSpec
C#: NSpec, NBehave
.NET: NSpec, NBehave, SpecFlow
PHP: PHPSpec, Behat
Ruby: RSpec, Cucumber
JavaScript: JSSpec, jspec
Phython: Freshen
Si estás pensando en implementar BDD en tus desarrollos, aquí te dejo algunas ventajas que beneficiarán al equipo de trabajo:
Referencia
Soeken, M., Wille, R., & Drechsler, R. (2012, May). Assisted behavior driven development using natural language processing. In International Conference on Modelling Techniques and Tools for Computer Performance Evaluation (pp. 269-287). Springer, Berlin, Heidelberg.
A diferencia de TDD, BDD se define en un idioma común entre todos los stakeholders, lo que mejora la comunicación entre equipos tecnológicos y no técnicos. Tanto en TDD como en BDD, las pruebas se deben definir antes del desarrollo, aunque en BDD, las pruebas se centran en el usuario y el comportamiento del sistema, a diferencia del TDD que se centra en funcionalidades.
En Behavior Driven Development (BDD), las pruebas de aceptación proporcionan el punto de partida para el flujo de diseño de software y sirven como base para la comunicación entre diseñadores y partes interesadas. En esta técnica de desarrollo de software ágil, las pruebas de aceptación se escriben en lenguaje natural para garantizar una comprensión común entre todos los miembros del proyecto. Como consecuencia, mapear las oraciones al código fuente real es el primer paso del flujo de diseño, que generalmente se realiza manualmente.
Sin embargo, los escenarios descritos por las pruebas de aceptación proporcionan suficiente información para automatizar la extracción tanto de la estructura de la implementación como de los casos de prueba. En este trabajo, proponemos un flujo asistido para BDD donde el usuario entra en un diálogo con la computadora que sugiere fragmentos de código extraídos de las oraciones. Para este propósito, se explotan las técnicas de procesamiento del lenguaje natural. Esto permite una transformación semiautomática de las pruebas de aceptación a los apéndices del código fuente y, por lo tanto, proporciona un primer paso hacia la automatización de BDD.
Características BDD
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.A diferencia de BDD, TDD funciona apropiadamente siempre que la dirección de la organización esté familiarizada con estas pruebas unitarias, en definitiva que sus habilidades técnicas sean lo suficientemente sólidas, y no siempre es así.
En estas circunstancias, la BDD tiene la ventaja de que las pruebas unitarias se pueden escribir en un lenguaje común utilizado por todas las partes interesadas. 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.
Beneficios esperados
Los equipos que ya usan TDD o ATDD pueden considerar BDD por varias razones:BDD ofrece una guía más precisa para organizar la conversación entre desarrolladores, evaluadores y expertos en dominios.
Las anotaciones que se originan en el enfoque de BDD, en particular el lienzo dado cuando entonces , están más cerca del lenguaje cotidiano y tienen una curva de aprendizaje más superficial en comparación con las de herramientas como Fit / FitNesse
Las herramientas dirigidas a un enfoque BDD generalmente permiten la generación automática de documentación técnica y de usuario final a partir de las "especificaciones" BDD
En este trabajo, propusimos un flujo asistido para BDD donde el usuario entra en un diálogo
con la computadora para generar semiautomáticamente definiciones de pasos y esqueletos de códigos a partir de un escenario dado. Para ello, herramientas de procesamiento del lenguaje natural.
Son explotados Un estudio de caso ilustró la aplicación. En lugar de pasar por el BDD establecido manualmente, el diseñador recibe automáticamente opciones que fácilmente se puede refinar.
El enfoque propuesto es un paso significativo hacia una automatización de BDD. Además, si bien el estudio de caso se centra en la prueba de aceptación dentro del esquema BDD. Los resultados del enfoque propuesto también motivan una consideración de la naturaleza general.
sistema de lenguaje específico.
¿Que debo tener en cuenta antes de implementar BDD?
Cada requisitos debe convertirse en historias de usuario, defiendo ejemplos concretos.Cada ejemplo debe ser un escenario de un usuario en el sistema.
Ser consciente de la necesidad de definir "la especificación del comportamiento de un usuario" en lugar de "la prueba unitaria de una clase".
Comprender la fórmula ‘Given-When-Then’ u otras como las historias de usuario ‘Role-Feature-Reason'. Veamos que tratan estas fórmulas.
Herramientas de 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.
Hay muchas otras herramientas, tantas como lenguajes de programación:
Java: JBehave, JDave, Instinct, beanSpec
C: CSpec
C#: NSpec, NBehave
.NET: NSpec, NBehave, SpecFlow
PHP: PHPSpec, Behat
Ruby: RSpec, Cucumber
JavaScript: JSSpec, jspec
Phython: Freshen
Ventajas de BDD (Behavior Driven Development)
Si estás pensando en implementar BDD en tus desarrollos, aquí te dejo algunas ventajas que beneficiarán al equipo de trabajo:
- 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 se específíca utilizando un lenguaje simplificado y común, la curva de aprendizaje es mucho más corta que TDD.
- 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.
Conclusión
BDD te permite desarrollar, probar y pensar el código desde la perspectiva del usuario. Debes tener la mentalidad de implementar 'ejemplos del mundo real' en lugar de implementar solo 'funcionalidades'. Las ventajas son muy considerable para integrar a todo el equipo con un objetivo común, además de empatizar con el usuario final de tus desarrollos.Referencia
Soeken, M., Wille, R., & Drechsler, R. (2012, May). Assisted behavior driven development using natural language processing. In International Conference on Modelling Techniques and Tools for Computer Performance Evaluation (pp. 269-287). Springer, Berlin, Heidelberg.
.png)
Comentarios