Desarrollo impulsado por el comportamiento

El desarrollo impulsado por el comportamiento ( BDD ) implica nombrar las pruebas de software utilizando el lenguaje del dominio para describir el comportamiento del código .

El BDD implica el uso de un lenguaje específico del dominio (DSL) utilizando construcciones de lenguaje natural (por ejemplo, oraciones similares al inglés) que pueden expresar el comportamiento y los resultados esperados.

Los defensores afirman que fomenta la colaboración entre desarrolladores, expertos en garantía de calidad y representantes de clientes en un proyecto de software. ^{[1] [2]} Fomenta que los equipos utilicen la conversación y ejemplos concretos para formalizar una comprensión compartida de cómo debería comportarse la aplicación. ^[3] BDD se considera una práctica eficaz, especialmente cuando el espacio del problema es complejo. ^[4]

El BDD se considera un refinamiento del desarrollo impulsado por pruebas (TDD). ^{[1] [5] [6] [ vago ] [7] [8]} El BDD combina las técnicas del TDD con ideas del diseño impulsado por dominios y el análisis y diseño orientado a objetos para proporcionar a los equipos de desarrollo y gestión de software herramientas compartidas y un proceso compartido para colaborar en el desarrollo de software. ^{[1] [7]}

En un nivel alto, BDD es una idea sobre cómo se debe gestionar el desarrollo de software tanto desde el punto de vista de los intereses comerciales como desde el punto de vista técnico. Su práctica implica el uso de herramientas especializadas. ^[5] Algunas herramientas específicas para BDD se pueden utilizar para TDD. Las herramientas automatizan el lenguaje omnipresente .

BDD es un proceso mediante el cual las instrucciones de lenguaje natural estructuradas de DSL se convierten en pruebas ejecutables. El resultado son pruebas que se leen como criterios de aceptación para una función determinada.

Como tal, BDD es una extensión de TDD.

BDD se centra en:

• Por dónde empezar en el proceso
• Qué probar y qué no probar
• ¿Cuánto probar de una sola vez?
• ¿Cómo llamar a las pruebas?
• Cómo entender por qué falla una prueba

En esencia, BDD trata de repensar el enfoque de las pruebas automatizadas (incluidas 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 ("debería" en inglés, por ejemplo) y que se escriban en orden de valor comercial. Las pruebas de aceptación se deben escribir 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 se deben escribir en términos de escenarios e implementar en clases: Dado [contexto inicial], cuando [evento ocurre], entonces [garantizar algunos resultados] .

A partir de este punto, muchas personas desarrollaron marcos BDD a lo largo de un período de años, y finalmente lo enmarcaron 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. ^[9]

BDD sugiere que las pruebas de software deben ser nombradas en términos de comportamiento deseado . ^{[5] [7]} Tomando prestado del desarrollo de software ágil, 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 encargó la unidad de software en construcción. ^[5] Dentro de la práctica de BDD, esto se conoce como BDD como una actividad "de afuera hacia adentro".

TDD no diferencia las pruebas en términos de requisitos de software de alto nivel, detalles técnicos de bajo nivel o algo intermedio. Por lo tanto, una forma de ver BDD es que es una evolución de TDD que toma decisiones más específicas.

Otra sugerencia de BDD se relaciona con la manera en que se debe especificar el comportamiento deseado. BDD sugiere utilizar un formato semiformal para la especificación del 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 de escenario de este formato puede considerarse como una aplicación de la lógica de Hoare a la especificación del comportamiento del software utilizando el lenguaje específico del dominio.

BDD sugiere que los analistas de negocios y los desarrolladores de software deberían colaborar en esta área y deberían especificar el comportamiento en términos de historias de usuario, cada una de las cuales debe estar documentada explícitamente. Cada historia de usuario debería, hasta cierto punto, seguir la estructura: ^[5]

Título

Un título explícito.

Narrativo

Una breve sección introductoria con la siguiente estructura:

• Como : la persona o rol que se beneficiará de la función;
• Quiero : la característica;
• de modo que : el beneficio o valor de la característica.

Criterios de aceptación

Una descripción de cada escenario específico de la narrativa con la siguiente estructura:

• Dado : el contexto inicial al comienzo del escenario, en una o más cláusulas;
• Cuándo : el evento que desencadena el escenario;
• Entonces : el resultado esperado, en una o más cláusulas.

BDD no requiere cómo se formatea esta información, pero sí sugiere que un equipo debe decidir sobre un formato relativamente simple y estandarizado con los elementos anteriores. ^[5] También sugiere que los escenarios deben redactarse de manera declarativa en lugar de imperativa, en el lenguaje empresarial, sin referencia a elementos de la interfaz de usuario a través de los cuales tienen lugar las interacciones. ^[10] Este formato se conoce en Cucumber como el lenguaje Gherkin .

BDD 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. ^[11] 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. ^[11] De esta manera, BDD se convierte en un vehículo para la comunicación entre todos los diferentes roles en un proyecto de software. ^[5]

Un riesgo común en el desarrollo de software incluye fallas en la comunicación entre desarrolladores y partes interesadas del negocio. ^[12] BDD utiliza la especificación del comportamiento deseado como un lenguaje ubicuo para los miembros del equipo del proyecto. Esta es la razón por la que BDD insiste en un lenguaje semiformal para la especificación del 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 se puedan razonar formalmente. ^[13] Este modelo también es la base de las diferentes herramientas de software de soporte de 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 se identifica 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 procesarse de alguna manera mediante 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, para fines de prueba. ^[14]

Al igual que TDD, BDD puede implicar el uso de herramientas especializadas.

BDD no solo requiere código de prueba como lo hace TDD, sino también un documento que describa el comportamiento en un lenguaje más legible para las personas. Esto requiere un proceso de dos pasos para ejecutar las pruebas, leer y analizar las descripciones, y leer el código de prueba y encontrar la implementación de prueba correspondiente para ejecutar. Este proceso hace que BDD sea más laborioso para los desarrolladores. Los defensores sugieren que debido a su naturaleza legible para las personas, el valor de esos documentos se extiende a una audiencia relativamente no 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 de BDD es un marco de prueba para software, muy similar a las herramientas que respaldan TDD. Sin embargo, mientras que las herramientas TDD tienden a ser bastante libres en cuanto a lo que se permite para especificar pruebas, las herramientas de BDD están vinculadas a la definición del lenguaje ubicuo.

El lenguaje ubicuo permite a los analistas de negocios documentar los requisitos de comportamiento de una manera que también será entendida por los desarrolladores. El principio de las herramientas de soporte de BDD es hacer que estos mismos documentos de requisitos sean directamente ejecutables como una colección de pruebas. Si esto no se puede lograr debido a razones relacionadas con la herramienta técnica que permite la ejecución de las especificaciones, entonces se debe alterar el estilo de redacción de los requisitos de comportamiento o se debe cambiar la herramienta. ^[15] 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:

• La herramienta lee un documento de especificaciones.
• La herramienta comprende directamente partes completamente formales del lenguaje ubicuo (como la palabra clave Given en el ejemplo anterior). En función de esto, la herramienta divide cada escenario en cláusulas significativas.
• Cada cláusula individual de un escenario se transforma en algún tipo de parámetro para una prueba de la historia de usuario. Esta parte requiere un trabajo específico del proyecto por parte de los desarrolladores de software.
• Luego, el marco ejecuta la prueba para cada escenario, con los parámetros de ese escenario.

Una subcategoría separada del desarrollo impulsado por el comportamiento está formada por herramientas que utilizan especificaciones como lenguaje de entrada en lugar de historias de usuario. Las herramientas de especificación no utilizan historias de usuario 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 usuario y suelen ser menos convenientes para la comunicación con el personal de la empresa que las historias de usuario. ^{[5] [16]} Un ejemplo de una especificación para una pila podría verse así:

Especificación: PilaCuando se crea una nueva pila , está vacía.Cuando se agrega un elemento a la pila , ese elemento se ubica 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 pop devuelve E y el nuevo tamaño de la pila es N-1

Una especificación de este tipo puede especificar con exactitud el comportamiento del componente que se está probando, pero es menos significativa para un usuario comercial. Como resultado, las pruebas basadas en especificaciones se consideran en la práctica de BDD como un complemento a las pruebas basadas en historias y funcionan a un nivel inferior. Las pruebas basadas en especificaciones a menudo se consideran un reemplazo de las pruebas unitarias de formato libre. ^[16]

El "Tres amigos", también conocido como "Taller de especificaciones", es una reunión en la que el propietario del producto analiza el requisito en forma de especificación mediante ejemplos con diferentes partes interesadas, como el equipo de control de calidad y el equipo de desarrollo. El objetivo principal de esta discusión es iniciar una conversación e identificar las especificaciones faltantes. La discusión también ofrece una plataforma para que el equipo de 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 construyendo el producto correcto. ^[17]

Los tres amigos son:

• Negocios - El rol del usuario comercial es solo definir el problema y no aventurarse a sugerir una solución.
• Desarrollo: el papel de los desarrolladores implica sugerir formas de solucionar el problema.
• Pruebas: el papel de los evaluadores es cuestionar la solución, plantear tantas posibilidades diferentes como sea posible para realizar una lluvia de ideas a través de escenarios hipotéticos y ayudar a que la solución sea más precisa para solucionar el problema.

• Especificación por ejemplo
• Behat (marco PHP)
• Marco de Cynefin
• Concordion (marco de Java)
• REspecificaciones
• Indicador
• Jasmine (marco de pruebas de JavaScript)
• Squish GUI Tester (herramienta de prueba de GUI de BDD para JavaScript, Python, Perl, Ruby y Tcl)
• Caso de uso
• Fitnesse se ha utilizado para implementar BDD ^[18]