En ingeniería de software , el desarrollo impulsado por el comportamiento ( BDD ) es un proceso de desarrollo de software que fomenta la colaboración entre desarrolladores, expertos en control de calidad y representantes del cliente en un proyecto de software. [1] [2] [3] Alienta 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) y puede funcionar junto con un proceso de desarrollo de software ágil . [1] [2] [5] [6] [ vago ] [7] El desarrollo impulsado por el comportamiento combina las técnicas y principios generales de TDD con ideas del diseño impulsado por dominio y el análisis y diseño orientado a objetos para proporcionar desarrollo y gestión de software. equipos con herramientas compartidas y un proceso compartido para colaborar en el desarrollo de software. [2] [7]
Aunque BDD es principalmente una idea sobre cómo se debe gestionar el desarrollo de software 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 herramientas que respaldan el desarrollo basado en pruebas. Las herramientas sirven para agregar automatización al lenguaje omnipresente que es un tema central de BDD.
El BDD se facilita en gran medida mediante el uso de un lenguaje de dominio específico (DSL) simple que utiliza 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. 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 basado en el comportamiento, una extensión del desarrollo basado en pruebas, [9] es un proceso de desarrollo que utiliza un DSL simple. Estos DSL convierten declaraciones estructuradas en 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.
BDD se centra en:
En esencia, BDD consiste en repensar el enfoque de las pruebas unitarias y de aceptación para evitar los 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/parte interesada], 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 [ocurra el evento], entonces [garantizar algunos resultados] .
A partir de este punto, muchas personas desarrollaron marcos BDD durante un período de años, enmarcándolos finalmente en términos de un marco de comunicación y colaboración para desarrolladores, control de calidad y participantes no técnicos o comerciales en un proyecto de software. [10] Durante el evento "Especificaciones ágiles, BDD y Testing eXchange" en noviembre de 2009 en Londres, Dan North [11] dio la siguiente descripción de BDD:
BDD es una metodología ágil de segunda generación, de afuera hacia adentro, basada en pull, de múltiples partes interesadas, de múltiples escalas, de alta automatización. Describe un ciclo de interacciones con resultados bien definidos, que dan como resultado la entrega de un software funcional y probado que importa.
Durante una entrevista con Dan North en la Conferencia GOTO en 2013, Liz Keogh [12] definió BDD como:
Se trata de usar ejemplos para hablar sobre cómo se comporta una aplicación... y tener conversaciones sobre esos ejemplos.[13]
Dan North creó un marco BDD, JBehave, seguido de un marco BDD a nivel de historia para Ruby llamado RBehave [14] que luego se integró en el proyecto RSpec . [15] También trabajó con David Chelimsky, Aslak Hellesøy y otros para desarrollar RSpec y también para escribir "El libro de RSpec: desarrollo impulsado por el comportamiento con RSpec, Cucumber y Friends". El primer marco basado en historias en RSpec fue reemplazado posteriormente por Cucumber desarrollado principalmente por Aslak Hellesøy. Capybara , que forma parte del marco de pruebas de Cucumber, es uno de esos software de automatización de pruebas basado en la web.
El desarrollo basado en pruebas es una metodología de desarrollo de software que esencialmente establece que para cada unidad de software, un desarrollador de software debe
Esta definición es bastante inespecífica en el sentido de que permite pruebas en términos de requisitos de software de alto nivel, detalles técnicos de bajo nivel o cualquier punto intermedio. Por lo tanto, una forma de ver el BDD es que se trata de un desarrollo continuo del TDD que toma decisiones más específicas que el TDD.
El desarrollo basado en el comportamiento especifica que las pruebas de cualquier unidad de software deben especificarse en términos del comportamiento deseado de la unidad. [5] [7] [1] Tomando prestado del desarrollo ágil de software, el "comportamiento deseado" en este caso consiste en los requisitos establecidos por la empresa, es decir, el comportamiento deseado que tiene valor comercial para cualquier entidad que haya encargado la unidad de software en construcción. . [5] [1] Dentro de la práctica de BDD, esto se conoce como BDD como una actividad "de afuera hacia adentro". [dieciséis]
Después de esta elección fundamental, una segunda elección hecha por BDD se relaciona con cómo se debe especificar el comportamiento deseado. En esta área, BDD elige utilizar un formato semiformal para la especificación de comportamiento que se toma prestado de las especificaciones de historias de usuario del campo del análisis y diseño orientado a objetos . El aspecto del escenario de este formato puede considerarse como una aplicación de la lógica de Hoare a la especificación del comportamiento de unidades de software utilizando el lenguaje específico del dominio de la situación.
BDD especifica que los analistas y desarrolladores de negocios deben colaborar en esta área y deben especificar el comportamiento en términos de historias de usuarios, cada una de las cuales está escrita explícitamente en un documento específico. [1] [16] Cada historia de usuario debe, de alguna manera, seguir la siguiente estructura: [5] [16]
BDD no tiene ningún requisito formal sobre cómo se deben escribir exactamente estas historias de usuario, pero sí insiste en que cada equipo que utilice BDD elabore un formato simple y estandarizado para escribir las historias de usuario que incluya los elementos enumerados anteriormente. [5] [16] Sin embargo, en 2007 Dan North sugirió una plantilla para un formato textual que ha encontrado un gran seguimiento en diferentes herramientas de software BDD. [16] Un ejemplo muy breve de este formato podría verse así:
Título : Las devoluciones y los cambios van al inventario.Como propietario de una tienda, quiero volver a agregar artículos al inventario cuando se devuelvan o cambien, para poder venderlos nuevamente.Escenario 1: Los artículos devueltos para reembolso deben agregarse al inventario.Dado que un cliente me compró previamente un suéter negro y tengo tres suéteres negros en el inventario, cuando me devuelvan el suéter negro para obtener un reembolso, entonces debería tener cuatro suéteres negros en el inventario.Escenario 2: los artículos intercambiados deben devolverse al inventario.Dado que un cliente me compró anteriormente una prenda azul y tengo dos prendas azules en inventario y tres prendas negras en inventario, cuando me cambian la prenda azul por una prenda negra, entonces debería tener tres prendas azules en inventario y dos prendas negras. En inventario.
Lo ideal es que los escenarios estén redactados de forma declarativa y no imperativa, en el lenguaje empresarial, sin hacer referencia a los elementos de la interfaz de usuario a través de los cuales se llevan a cabo las interacciones. [17]
Este formato se conoce como lenguaje Gherkin y tiene una sintaxis similar al ejemplo anterior. El término Gherkin , sin embargo, es específico de las herramientas de software Cucumber , JBehave, Lettuce, [18] Behate y Behat . [19] [20] [21] [22]
El desarrollo impulsado por el comportamiento toma prestado el concepto de lenguaje ubicuo del diseño impulsado por el dominio . [5] [7] Un lenguaje ubicuo es un lenguaje (semi)formal que comparten todos los miembros de un equipo de desarrollo de software, tanto desarrolladores de software como personal no técnico. [23] El lenguaje en cuestión es utilizado y desarrollado por todos los miembros del equipo como un medio común para discutir el dominio del software en cuestión. [23] De esta manera, BDD se convierte en un vehículo para la comunicación entre los diferentes roles en un proyecto de software. [5] [24]
Un riesgo común en el desarrollo de software incluye fallas en la comunicación entre los desarrolladores y las partes interesadas del negocio. [25] BDD utiliza la especificación del comportamiento deseado como un lenguaje omnipresente para los miembros del equipo del proyecto. Ésta es la razón por la que BDD insiste en un lenguaje semiformal para la especificación de comportamiento: cierta formalidad es un requisito para ser un lenguaje ubicuo. [5] Además, tener un lenguaje tan ubicuo crea un modelo de dominio de especificaciones, de modo que las especificaciones pueden ser razonadas formalmente. [26] Este modelo es también la base de las diferentes herramientas de software de soporte BDD que están disponibles.
El ejemplo anterior establece una historia de usuario para un sistema de software en desarrollo. Esta historia de usuario identifica una parte interesada, un efecto comercial y un valor comercial. También describe varios escenarios, cada uno con una condición previa, un desencadenante y un resultado esperado. Cada una de estas partes está identificada exactamente por la parte más formal del lenguaje (el término Dado podría considerarse una palabra clave , por ejemplo) y, por lo tanto, puede ser procesada de alguna manera por una herramienta que comprenda las partes formales del lenguaje ubicuo.
La mayoría de las aplicaciones BDD utilizan DSL basados en texto y enfoques de especificación. Sin embargo, el modelado gráfico de escenarios de integración también se ha aplicado con éxito en la práctica, por ejemplo, con fines de prueba. [27]
Al igual que la práctica del diseño basado en pruebas, el desarrollo basado en comportamiento supone el uso de herramientas de soporte especializadas en un proyecto. BDD puede verse como una versión más específica de TDD, ya que requiere proporcionar no solo un código de prueba sino un documento separado además de describir el comportamiento en un lenguaje más legible para los humanos. Esto requiere un proceso de dos pasos para ejecutar las pruebas, leer y analizar las descripciones, leer el código de prueba y encontrar la implementación de prueba correspondiente para ejecutar. Este proceso hace que trabajar con BDD como desarrollador sea un poco más laborioso, pero debido a su naturaleza legible por humanos, el valor de esos documentos se extiende a una audiencia aún menos técnica y, por lo tanto, puede servir como un medio de comunicación para describir los requisitos ("características"). ).
En principio, una herramienta de soporte BDD es un marco de prueba para software, muy parecido a las herramientas que soportan TDD. Sin embargo, mientras que las herramientas TDD tienden a tener un formato bastante libre en lo que se permite para especificar pruebas, las herramientas BDD están vinculadas a la definición del lenguaje ubicuo discutido anteriormente.
Como se mencionó, el lenguaje omnipresente permite a los analistas de negocios escribir requisitos de comportamiento de una manera que también sean entendidos por los desarrolladores. El principio de las herramientas de soporte BDD es hacer que estos mismos documentos de requisitos sean directamente ejecutables como una colección de pruebas. Si esto no se puede lograr por razones relacionadas con la herramienta técnica que permite la ejecución de las especificaciones, entonces se debe modificar el estilo de redacción de los requisitos de comportamiento o se debe cambiar la herramienta. [28] La implementación exacta de los requisitos de comportamiento varía según la herramienta, pero la práctica ágil ha llegado al siguiente proceso general:
Dan North ha desarrollado una serie de marcos que admiten BDD (incluidos JBehave y RBehave), cuyo funcionamiento se basa en la plantilla que sugirió para registrar historias de usuarios. [5] Estas herramientas utilizan una descripción textual para los casos de uso y varias otras herramientas (como CBehave) han seguido su ejemplo. Sin embargo, este formato no es necesario, por lo que existen otras herramientas que también utilizan otros formatos. Por ejemplo, Fitnesse (que se basa en tablas de decisión ) también se ha utilizado para implementar BDD. [29]
Existen varios ejemplos diferentes de herramientas de software BDD que se utilizan en proyectos actuales, para diferentes plataformas y lenguajes de programación.
Posiblemente el más conocido sea JBehave, desarrollado por Dan North, Elizabeth Keogh y varios otros. [30] El siguiente es un ejemplo tomado de ese proyecto: [20]
Consideremos una implementación del Juego de la Vida . Un experto en el dominio (o analista de negocios) podría querer especificar qué debería suceder cuando alguien establece una configuración inicial de la cuadrícula del juego. Para hacer esto, podría querer dar un ejemplo de una serie de pasos dados por una persona que está alternando celdas. Saltándose la parte narrativa, podría hacerlo escribiendo el siguiente escenario en un documento de texto plano (que es el tipo de documento de entrada que lee JBehave):
Dado un juego de 5 por 5 Cuando cambio la celda en (3, 2) Entonces la cuadrícula debería verse así.................X.......Cuando cambio la celda en (3, 1), la cuadrícula debería verse así.................X....X..Cuando cambio la celda en (3, 2), la cuadrícula debería verse así......................X..
La letra en negrita no forma parte de la entrada; se incluye aquí para mostrar qué palabras se reconocen como lenguaje formal. JBehave reconoce los términos Dado (como una condición previa que define el inicio de un escenario), Cuándo (como un evento desencadenante) y Entonces (como una poscondición que debe verificarse como el resultado de la acción que sigue al desencadenante). En base a esto, JBehave es capaz de leer el archivo de texto que contiene el escenario y analizarlo en cláusulas (una cláusula de configuración y luego tres activadores de eventos con condiciones verificables). Luego, JBehave toma estas cláusulas y las pasa a un código que es capaz de establecer una prueba, responder a los desencadenantes de eventos y verificar el resultado. Este código debe ser escrito por los desarrolladores del equipo del proyecto (en Java , porque esa es la plataforma en la que se basa JBehave). En este caso, el código podría verse así:
Juego privado ; renderizador StringRenderer privado ; @Given ( "un juego de $ancho por $alto" ) public void theGameIsRunning ( int ancho , int alto ) { juego = nuevo juego ( ancho , alto ); renderizador = nuevo StringRenderer (); juego . setObserver ( renderizador ); } @When ( "Alterno la celda en ($columna, $fila)" ) public void iToggleTheCellAt ( int columna , int fila ) { juego . toggleCellAt ( columna , fila ); } @Then ( "la cuadrícula debería verse como $grid" ) public void theGridShouldLookLike ( String grid ) { afirmarEso ( renderer . asString (), equalTo ( grid )); } El código tiene un método para cada tipo de cláusula en un escenario. JBehave identificará qué método va con cada cláusula mediante el uso de anotaciones y llamará a cada método en orden mientras se ejecuta el escenario. Se espera que el texto de cada cláusula del escenario coincida con el texto de plantilla proporcionado en el código de esa cláusula (por ejemplo, se espera que un Dado en un escenario vaya seguido de una cláusula del formato "un juego de X por Y") . JBehave admite la coincidencia de cláusulas con plantillas y tiene soporte integrado para seleccionar términos de la plantilla y pasarlos a métodos en el código de prueba como parámetros. El código de prueba proporciona una implementación para cada tipo de cláusula en un escenario que interactúa con el código que se está probando y realiza una prueba basada en el escenario. En este caso:
theGameIsRunningmétodo reacciona a una cláusula dada configurando la cuadrícula de juego inicial.iToggleTheCellAtmétodo reacciona a una cláusula When activando el evento de alternancia descrito en la cláusula.theGridShouldLookLikemétodo reacciona a una cláusula Then comparando el estado de la cuadrícula del juego con el estado esperado del escenario.La función principal de este código es ser un puente entre un archivo de texto con una historia y el código que se está probando. Tenga en cuenta que el código de prueba tiene acceso al código que se está probando (en este caso, una instancia de Game) y es de naturaleza muy simple. El código de prueba tiene que ser simple; de lo contrario, un desarrollador terminaría teniendo que escribir pruebas para sus pruebas.
Finalmente, para ejecutar las pruebas, JBehave requiere algún código de plomería que identifique los archivos de texto que contienen escenarios y que inyectan dependencias (como instancias de Game) en el código de prueba. Este código de plomería no se ilustra aquí, ya que es un requisito técnico de JBehave y no se relaciona directamente con el principio de prueba de estilo BDD.
Una subcategoría separada de desarrollo impulsado por el comportamiento está formada por herramientas que utilizan especificaciones como lenguaje de entrada en lugar de historias de usuarios. Un ejemplo de este estilo es la herramienta RSpec que también fue desarrollada originalmente por Dan North. Las herramientas de especificación no utilizan historias de usuarios como formato de entrada para escenarios de prueba , sino que utilizan especificaciones funcionales para las unidades que se están probando. Estas especificaciones suelen tener una naturaleza más técnica que las historias de usuarios y suelen ser menos convenientes para la comunicación con el personal empresarial que las historias de usuarios. [5] [31] Un ejemplo de especificación para una pila podría verse así:
Especificación: pilaCuando se crea una nueva pila, entonces está vacíaCuando se agrega un elemento a la pila, entonces ese elemento está en la parte superior de la pila.Cuando una pila tiene N elementos y el elemento E está en la parte superior de la pila , entonces una operación emergente devuelve E y el nuevo tamaño de la pila es N-1
Una especificación de este tipo puede especificar exactamente el comportamiento del componente que se está probando, pero es menos significativa para un usuario empresarial. Como resultado, las pruebas basadas en especificaciones se consideran en la práctica de BDD como un complemento de las pruebas basadas en historias y operan en un nivel inferior. Las pruebas de especificaciones a menudo se consideran un reemplazo de las pruebas unitarias de formato libre. [31]
Las herramientas de prueba de especificaciones como RSpec y JDave son de naturaleza algo diferente a herramientas como JBehave. Dado que se consideran alternativas a las herramientas de prueba unitarias básicas como JUnit , estas herramientas tienden a favorecer la separación de la historia y el código de prueba y prefieren incrustar la especificación directamente en el código de prueba. Por ejemplo, una prueba RSpec para una tabla hash podría verse así: [32]
describe Hash haz let ( :hash ) { Hash [ :hola , 'mundo' ] } it { esperar ( Hash.nuevo ) . _ _ a la ecuación ({}) } " codifica la información correcta en una clave", espere ( hash [ : hello ] ) . al final de eq ( 'mundo' ) ' incluye clave' hacer hash . llaves . ¿incluir? ( :Hola ) . debe ser cierto final final Este ejemplo muestra una especificación en lenguaje legible integrada en código ejecutable. En este caso, una opción de la herramienta es formalizar el lenguaje de especificación en el lenguaje del código de prueba agregando métodos denominados ity should. También existe el concepto de condición previa de especificación: la beforesección establece las condiciones previas en las que se basa la especificación.
El resultado de la prueba será:
Picadillo debería eq {} incluye llave codifica la información correcta en una claveLos Tres Amigos, también conocidos como "Taller de especificaciones", es una reunión en la que el propietario del producto analiza el requisito en forma de especificación por ejemplo con diferentes partes interesadas, como el equipo de control de calidad y de desarrollo. El objetivo clave de esta discusión es iniciar la conversación e identificar las especificaciones faltantes. La discusión también brinda una plataforma para que el control de calidad, el equipo de desarrollo y el propietario del producto converjan y escuchen las perspectivas de los demás para enriquecer el requisito y también asegurarse de que están creando el producto correcto. [33]
Los tres amigos son