 |
| Imagen de: Rachel Davies |
El Behaviour-driven development (BDD) es un procedimiento de ingeniería de software desarrollado por Dan North como una mejora del Test-Driven Development (TDD).
En español, BDD significa “Desarrollo guiado por comportamientos”, así como de manera similar, TDD se traduce al español como “Desarrollo guiado por pruebas”.
La idea básica del Behaviour-Driven Development (BDD) es explorar, descubrir y luego desarrollar el comportamiento deseado del software, usando conversaciones, ejemplos concretos y pruebas automatizadas.
Al igual que TDD, BDD requiere validar los comportamientos ejecutando pruebas una y otra vez, haciendo necesaria una herramienta de automatización de software testing. Cucumber es una herramienta orientada específicamente a implementar el BDD.
PMOInformatica presenta a continuación Desarrollo de sistemas con Behaviour-Driven Development y Cucumber:
En BDD, primero, el equipo de desarrollo y el equipo gerencial, incluyendo analistas de negocio, testers y personas del área de negocio (usuarios), describen lo que se requiere que el sistema haga, en conversaciones donde se desarrollan comportamientos de ejemplo.
Luego, el equipo de desarrollo trabaja “de afuera hacia adentro” para implementar esos comportamientos, utilizando los ejemplos discutidos para validar el desarrollo, usando pruebas unitarias y pruebas funcionales automatizadas.
BDD es una combinación de técnicas y principios del TDD con ideas del “domain-driven design” (Diseño guiado por dominios) y del análisis y diseño orientado a objetos.
El enfoque suministra prácticas y herramientas que crean un lenguaje común entre desarrolladores y equipo gerencial.
Más Información sobre Software Testing
> Visita nuestra página de Recursos en Pruebas de Software
¿Cuáles son las bases del BDD?
Cuando Dan North desarrolló el BDD, lo hizo como respuesta a una serie de problemas recurrentes con los que se había encontrado a lo largo del tiempo mientras ejecutaba proyectos y enseñaba el enfoque TDD a sus alumnos.
Estas dificultades con las que se encontraba eran:
Para cada uno de estos problemas, Dan North modificó el método del desarrollo guiado por pruebas (TDD) para resolverlos, a saber:
Dado [Algún contexto inicial] Cuando [Ocurra un determinado evento] Entonces [resultado que debe asegurarse que ocurra]
Este lenguaje que permitía describir los comportamientos en texto plano que todos pudieran entender, fue evolucionando en la comunidad ágil, dando nacimiento al lenguaje “Gherkin”.
¿Cuáles son los pasos del BDD?
Sigue una secuencia de pasos bastante similar a la del TDD. Como muestra la siguiente figura:
Algunas consideraciones:
¿Por qué usar BDD?
Algunas de las ventajas de BDD son:
¿Es imprescindible la automatización de pruebas para aplicar con éxito BDD?
Tanto TDD como BDD son enfoques que necesitan la aplicación constante y de forma iterativa de pruebas de software, pues en ambos casos se sigue el método de probar el software primero, estudiar las causas de falló de la prueba y agregar funcionalidad hasta que la prueba pase.
Realizar esto con pruebas manuales no es práctico, debido a que el preparar los datos de prueba, cargarlos y procesarlos tendría que repetirse una y otra vez, desperdiciando tiempo valioso. Es por ello que se hace imprescindible el uso de herramientas de software testing automatizado.
5 Preguntas y Respuestas sobre Cucumber
Una vez escritas en lenguaje “Gherkin”, Cucumber se encarga de traducir las pruebas a lenguaje Ruby, el cual es código ejecutable con el que puede probarse la aplicación.
Esto se logra porque “Gherkin” usa etiquetas especificas, que luego un parser integrado con Cucumber es capaz de relacionar con una etiqueta de Ruby correspondiente, de esta forma las pruebas quedan escritas en código ejecutable por el computador.
Con este enfoque Cucumber te permite ejecutar pruebas automatizadas sobre aplicaciones web que pueden estar desarroladas Java, .NET, Flex, el mismo Ruby o cualquier aplicación web de cualquier lenguaje.
¿Y qué opinas tú?
¿Has aplicado el test-driven development (TDD) o behaviour-driven development (BDD)? ¿Cuáles fueron las dificultades que encontraste y como las superaste?, ¿Qué herramienta de automatización de las pruebas utilizaste?
¿Buscas más información de metodologías de desarrollo de software?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de desarrollo de software?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Artículos similares
> Testing de Aceptación Automatizado con Selenium
En español, BDD significa “Desarrollo guiado por comportamientos”, así como de manera similar, TDD se traduce al español como “Desarrollo guiado por pruebas”.
La idea básica del Behaviour-Driven Development (BDD) es explorar, descubrir y luego desarrollar el comportamiento deseado del software, usando conversaciones, ejemplos concretos y pruebas automatizadas.
Al igual que TDD, BDD requiere validar los comportamientos ejecutando pruebas una y otra vez, haciendo necesaria una herramienta de automatización de software testing. Cucumber es una herramienta orientada específicamente a implementar el BDD.
PMOInformatica presenta a continuación Desarrollo de sistemas con Behaviour-Driven Development y Cucumber:
¿Qué es el Behaviour-driven Development (BDD)?
BDD fue desarrollador por Dan North como una mejora al TDD, antes de continuar, te recomendamos revisar nuestra serie sobre el Test-Driven Development en el siguiente enlace:
BDD fue desarrollador por Dan North como una mejora al TDD, antes de continuar, te recomendamos revisar nuestra serie sobre el Test-Driven Development en el siguiente enlace:
En BDD, primero, el equipo de desarrollo y el equipo gerencial, incluyendo analistas de negocio, testers y personas del área de negocio (usuarios), describen lo que se requiere que el sistema haga, en conversaciones donde se desarrollan comportamientos de ejemplo.
Luego, el equipo de desarrollo trabaja “de afuera hacia adentro” para implementar esos comportamientos, utilizando los ejemplos discutidos para validar el desarrollo, usando pruebas unitarias y pruebas funcionales automatizadas.
BDD es una combinación de técnicas y principios del TDD con ideas del “domain-driven design” (Diseño guiado por dominios) y del análisis y diseño orientado a objetos.
El enfoque suministra prácticas y herramientas que crean un lenguaje común entre desarrolladores y equipo gerencial.
> Visita nuestra página de Recursos en Pruebas de Software
¿Cuáles son las bases del BDD?
Cuando Dan North desarrolló el BDD, lo hizo como respuesta a una serie de problemas recurrentes con los que se había encontrado a lo largo del tiempo mientras ejecutaba proyectos y enseñaba el enfoque TDD a sus alumnos.
Estas dificultades con las que se encontraba eran:
- Confusión al no saber por dónde empezar el proceso TDD (que fue primero, el huevo o la gallina, es decir el desarrollo o las pruebas).
- Como distinguir entre que debe probarse y que no.
- Cuantas pruebas debían hacerse en un ciclo o pasada.
- Que nombres colocar a las pruebas.
- No entender las causas e falla de las pruebas.
Para cada uno de estos problemas, Dan North modificó el método del desarrollo guiado por pruebas (TDD) para resolverlos, a saber:
- Expresar los métodos de las clases (programas) de pruebas como oraciones:
- Por ejemplo, métodos escritos en lenguaje de programación como testFindsCustomerById o testFailsForDuplicateCustomers, se pueden traducir a “Finds Customer By Id” y “Fails For Duplicate Customers”.
- Este lenguaje “ubicuo” puede entenderse en conversaciones con los usuarios de negocio, analistas y testers.
- Comenzar los nombres de los métodos de prueba con la palabra “Debe” (Should):
- Por ejemplo escribiendo los métodos de prueba como testShouldFailForMissingSurname y testShouldFailForMissingTitle.
- Sirve de guía sobre cuando debo escribir otra clase, siguiendo el principio que una clase no debe hacer más de una cosa.
- Cuando traducimos los métodos escritos de esta forma a oraciones, por ejemplo “Should Fail For Missing Surname” y “Should Fail For Missing Title” nos es más fácil entender las causas por las que una prueba puede fallar.
- Hablar de “comportamientos” (behaviour) en lugar de “pruebas”:
- Decidir qué nombre colocar a las pruebas se hace más fácil, simplemente el próximo comportamiento en el que estoy interesado.
- Decidir cuánto probar, que probar y que no probar se facilita, pues simplemente debes circunscribirte al comportamiento descrito en la oración.
- Entender porque la prueba falla también se facilita, con 3 posibles razones: Se ha introducido un error, el comportamiento cambio o la prueba ya no es relevante.
- Las pruebas pasan a escribirse con la palabra “Behaviour”, por ejemplo en lugar de CustomerLookup escribimos CustomerLookupBehaviour.
- Determinar el próximo comportamiento a desarrollar:
- Luego de desarrollar un comportamiento y hacer que su prueba “pase”, me pregunto “¿Cual es la cosa más importante para el negocio que el sistema no hace todavía?”
- Contestas esta pregunta considerando el próximo comportamiento que tiene mayor valor para el área de negocio. Es decir, priorizas los comportamientos según sus necesidades.
- Con esto resuelves el problema de “por donde iniciar” o cual es el próximo paso.
- BDD proporciona un lenguaje ubicuo para realizar el análisis:
- Dan North se dio cuenta que los principios descritos anteriormente, eran lo mismo que realizar el análisis de requerimientos o ingeniería de requisitos.
- Se dio a la tarea de desarrollar un lenguaje ubicuo que defina un vocabulario consistente entre analistas, desarrolladores, testers y el área de negocio.
- De esta forma desarrollo una plantilla para describir los comportamientos.
Dado [Algún contexto inicial] Cuando [Ocurra un determinado evento] Entonces [resultado que debe asegurarse que ocurra]
Este lenguaje que permitía describir los comportamientos en texto plano que todos pudieran entender, fue evolucionando en la comunidad ágil, dando nacimiento al lenguaje “Gherkin”.
¿Cuáles son los pasos del BDD?
Sigue una secuencia de pasos bastante similar a la del TDD. Como muestra la siguiente figura:
 |
| Imagen de: AndolaSoft |
Algunas consideraciones:
- No es necesario involucrar a todo el equipo, pero si recomendable traer representantes de distintas áreas con distintos puntos de vista, enriqueciendo las conversaciones de los ejemplos.
- Estas conversaciones pueden ser instancias en las que el cliente (ej. El Product Owner de Scrum) describe lo que quiere y los desarrolladores hacen preguntas, obteniendo los detalles de los comportamientos.
- Con la presencia de analistas de negocio y testers se puede aún más detallar los escenarios de comportamiento.
- BDD es más que el TDD pues se enfoca en colaborar con las personas del área de negocio. De hecho, el conversar los casos en un lenguaje ubicuo como “Gherkin” los mantiene más involucrados y hace más productivas las reuniones.
- Los ejemplos luego son convertidos en pruebas automatizadas, siguiendo las ideas básicas del Acceptance Test-Driven Development (ATDD), en las cuales se elaboran pruebas de aceptación automatizadas para cada historia de usuario.
¿Por qué usar BDD?
Algunas de las ventajas de BDD son:
- Se priorizan las necesidades del negocio y primero se producen las funcionalidades de mayor valor para este.
- Menor cantidad de errores en el software.
- Menores costos de desarrollo y mantenimiento de software.
- Reducción en el “Time to market”, produciendo funcionalidades de mayor impacto (positivo) para el área de negocio en menos tiempo.
Las razones por las cuales es recomendable usar el BDD, son muy similares a las ventajas y desventajas del Test Driven Development (TDD).
Tanto TDD como BDD son enfoques que necesitan la aplicación constante y de forma iterativa de pruebas de software, pues en ambos casos se sigue el método de probar el software primero, estudiar las causas de falló de la prueba y agregar funcionalidad hasta que la prueba pase.
Realizar esto con pruebas manuales no es práctico, debido a que el preparar los datos de prueba, cargarlos y procesarlos tendría que repetirse una y otra vez, desperdiciando tiempo valioso. Es por ello que se hace imprescindible el uso de herramientas de software testing automatizado.
Las herramientas a usar son similares a las del TDD, solamente que estas deben ser capaces de permitir la definición de casos de comportamiento en lenguaje “ubicuo”, el cual luego se traduce a código ejecutable.
La herramienta Cucumber, soporta el lenguaje ubicuo y está específicamente diseñada para aplicar BDD.
¿Como puedo implementar Behaviour-driven development con Cucumber?
Cucumber te permite implementar BDD, pues puedes escribir las pruebas usando un lenguaje “Gherkin”, el cual es un lenguaje ubicuo, que pueden entenderlo tanto desarrolladores de software como no desarrolladores.
Para mayor información sobre cómo usar Cucumber, te recomendamos el siguiente artículo:
La herramienta Cucumber, soporta el lenguaje ubicuo y está específicamente diseñada para aplicar BDD.
¿Como puedo implementar Behaviour-driven development con Cucumber?
Cucumber te permite implementar BDD, pues puedes escribir las pruebas usando un lenguaje “Gherkin”, el cual es un lenguaje ubicuo, que pueden entenderlo tanto desarrolladores de software como no desarrolladores.
Para mayor información sobre cómo usar Cucumber, te recomendamos el siguiente artículo:
5 Preguntas y Respuestas sobre Cucumber
Una vez escritas en lenguaje “Gherkin”, Cucumber se encarga de traducir las pruebas a lenguaje Ruby, el cual es código ejecutable con el que puede probarse la aplicación.
Esto se logra porque “Gherkin” usa etiquetas especificas, que luego un parser integrado con Cucumber es capaz de relacionar con una etiqueta de Ruby correspondiente, de esta forma las pruebas quedan escritas en código ejecutable por el computador.
Con este enfoque Cucumber te permite ejecutar pruebas automatizadas sobre aplicaciones web que pueden estar desarroladas Java, .NET, Flex, el mismo Ruby o cualquier aplicación web de cualquier lenguaje.
¿Y qué opinas tú?
¿Has aplicado el test-driven development (TDD) o behaviour-driven development (BDD)? ¿Cuáles fueron las dificultades que encontraste y como las superaste?, ¿Qué herramienta de automatización de las pruebas utilizaste?
¿Buscas más información de metodologías de desarrollo de software?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de desarrollo de software?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
> Testing de Aceptación Automatizado con Selenium
No hay comentarios :
Publicar un comentario