En ingeniería de software , el desarrollo impulsado por el comportamiento ( BDD ) es un proceso de desarrollo de software ágil que fomenta la colaboración entre desarrolladores, evaluadores de control de calidad y representantes de clientes en un proyecto de software. [1] [2] [3] Anima a los equipos a utilizar conversaciones y ejemplos concretos para formalizar una comprensión compartida de cómo debe comportarse la aplicación. [4] Surgió del desarrollo basado en pruebas (TDD). [1] [2] [5] [6] [ vago ] [7]El desarrollo impulsado por el comportamiento combina las técnicas y principios generales de TDD con ideas de diseño impulsado por dominios y análisis y diseño orientados a objetos para proporcionar a los equipos de gestión y desarrollo de software herramientas compartidas y un proceso compartido para colaborar en el desarrollo de software. [2] [7]
Aunque BDD es principalmente una idea sobre cómo el desarrollo de software debe ser gestionado tanto por intereses comerciales como por conocimientos técnicos, la práctica de BDD supone el uso de herramientas de software especializadas para respaldar el proceso de desarrollo. [5] Aunque estas herramientas a menudo se desarrollan específicamente para su uso en proyectos BDD, pueden verse como formas especializadas de las herramientas que respaldan el desarrollo basado en pruebas. Las herramientas sirven para agregar automatización al lenguaje ubicuo que es un tema central de BDD.
BDD se facilita en gran medida mediante el uso de un lenguaje específico de dominio simple (DSL) utilizando construcciones de lenguaje natural (por ejemplo, oraciones similares al inglés) que pueden expresar el comportamiento y los resultados esperados. Los scripts de prueba han sido durante mucho tiempo una aplicación popular de DSL con diversos grados de sofisticación. La BDD se considera una práctica técnica eficaz, especialmente cuando el "espacio problemático" del problema empresarial a resolver es complejo. [8]
El desarrollo impulsado por el comportamiento es una extensión del desarrollo impulsado por pruebas, [9] un proceso de desarrollo que hace uso de un DSL simple. Estos DSL convierten declaraciones estructuradas de lenguaje natural en pruebas ejecutables. El resultado es una relación más estrecha con los criterios de aceptación para una función determinada y las pruebas utilizadas para validar esa funcionalidad. Como tal, es una extensión natural de las pruebas TDD en general.
En esencia, BDD se trata de repensar el enfoque de las pruebas unitarias y las pruebas de aceptación para evitar problemas que surgen naturalmente. Por ejemplo, BDD sugiere que los nombres de las pruebas unitarias sean oraciones completas que comiencen con un verbo condicional ("should" en inglés, por ejemplo) y deben escribirse en orden de valor comercial. Las pruebas de aceptación deben escribirse utilizando el marco ágil estándar de una historia de usuario : "Siendo un [rol / actor / interesado] quiero una [característica / capacidad] que produzca un [beneficio]". Los criterios de aceptación deben escribirse en términos de escenarios e implementarse en clases: Dado [contexto inicial], cuando [ocurre el evento], entonces [asegurar algunos resultados] .
A partir de este punto, muchas personas desarrollaron marcos BDD durante un período de años, finalmente enmarcándolos en términos de un marco de comunicación y colaboración para desarrolladores, QA y participantes no técnicos o comerciales en un proyecto de software. [10] Durante las "Especificaciones ágiles, BDD y Testing eXchange" en noviembre de 2009 en Londres, Dan North [11] dio la siguiente descripción de BDD: