En la Ingeniería de Software, behavior-driven development (BDD) o desarrollo guiado por el comportamiento (DGC), es un proceso de desarrollo de software que surgió a partir del desarrollo guiado por pruebas (DGP o TDD). El desarrollo guiado por el comportamiento combina las técnicas generales y los principios del DGP, junto con ideas del diseño guiado por el dominio y el análisis y diseño orientado a objetos para proveer al desarrollo de software y a los equipos de administración de herramientas compartidas y un proceso compartido de colaboración en el desarrollo de software.
Aunque el DGC es esencialmente una idea sobre cómo el desarrollo de software debería ser administrado tanto por los intereses del negocio como por el entendimiento técnico, la práctica del DGC asume el uso de herramientas de software especializadas para asistir en el proceso de desarrollo. Aunque estas herramientas son comúnmente desarrolladas específicamente para su uso en proyectos de DGC, se pueden ver como formas especializadas de las herramientas que asisten en el DGP. Las herramientas sirven para agregar automatización para el lenguaje ubicuo (lenguaje estructurado alrededor del modelo de dominio, utilizado en el diseño guiado por el dominio para conectar actividades entre miembros del equipo), el cual es el tema central del DGC.
El desarrollo guiado por el comportamiento fue desarrollado por Dan North como respuesta a los problemas que surgían al enseñar el desarrollo guiado por pruebas:
En el corazón del DGC existe una reconsideración de la aproximación a la prueba unitaria y a la prueba de validación que North sugirió mientras lidiaba con estos problemas. Por ejemplo, él propone que los nombres de las pruebas unitarias sean oraciones completas empezando con la palabra "deber"/"debería" y que deberían estar escritas en el orden de importancia de rentabilidad en el negocio. Las pruebas de validación deberían estar escritas usando el armazón estándar ágil de una historia de usuario: "Como un [rol] yo deseo [características] para que así exista [beneficio]". Los criterios de validación deberían estar escritos en términos de las situaciones y además implementados como cláusulas: (usando el principio Given-When-Then) Dado que [contexto inicial], cuando [ocurre el evento], entonces [asegurar algunos resultados].
A partir de este punto, North y otros desarrollaron el armazón del DGC en el transcurso de algunos años, finalmente enmarcándolo como un armazón de comunicación y colaboración para desarrolladores, para el aseguramiento de la calidad y para participantes no técnicos o enfocados en los negocios en un proyecto de software. Durante el congreso "Especificaciones ágiles, DGC y Pruebas" ("Agile specifications, BDD and Testing eXchange") en noviembre de 2009 en Londres, Dan North dio la siguiente descripción del DGC:
El DGC es una metodología ágil de segunda generación, tipo afuera hacia adentro, basada en jalar, siendo vehículo de múltiples partes interesadas, de escala múltiple, y de alta automatización. Describe un ciclo de interacciones con producciones bien definidas, resultando en el envío de software funcional, probado y trascendente.
Dan North creó el primer armazón del DGC, JBehave, seguido por un armazón nivel de historia DGC para Ruby llamado RBehave, el cual fue integrado más tarde al proyecto RSpec. North también colaboró con David Chelimsky, Aslak Hellesøy entre otros, para desarrollar RSpec y también para escribir el libro "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". El primer armazón basado en historia dentro de RSpec fue reemplazado poco tiempo después por Cucumber, principalmente desarrollado por Aslak Hellesøy.
En el 2008, Chris Matts, quien estuvo involucrado en las primeras discusiones alrededor del DGC, ideó el Feature Injection (inserción de característica), logrando así que el DGC pudiera cubrir el espacio de análisis y proveer un tratamiento completo al ciclo de vida del software, desde la visión hasta el código y el lanzamiento.
En sí, el desarrollo guiado por el comportamiento es una forma especializada de la lógica de Hoare aplicada al desarrollo guiado por pruebas, y que finalmente se enfoca en especificaciones conductistas acerca de las unidades de software que usan el lenguaje del dominio de la situación.
El desarrollo guiado por pruebas (TDD) es una metodología de desarrollo de software que esencialmente afirma que por cada unidad de software, un desarrollador de software debe:
Esta definición es poco específica, referente a que permite pruebas en términos de requerimientos de software de alto nivel, detalles técnicos de bajo nivel o cualquier cosa entre éstos límites. El desarrollador original del DGC (Dan North) propuso la noción del DGC debido a que no estaba satisfecho con la falta de especificaciones dentro del DGP, referente a lo que debe ser probado y cómo. Una forma de ver al DGC entonces, es que es un desarrollo continuo del DGP, por lo que toma decisiones más específicas que el DGP.
El desarrollo guiado por el comportamiento señala que las pruebas de cualquier unidad de software deben ser especificadas en términos del comportamiento deseado de la unidad. Tomando prestado del desarrollo ágil de software, el concepto de "comportamiento deseado" en este caso consiste en los requerimientos definidos por el negocio -- esto es, el comportamiento deseado que tiene valor rentable para cualquier entidad que haya comisionado la unidad de software que se encuentra en construcción. Dentro de la práctica del DGC, esto es lo que apunta a que el DGC es una actividad "afuera-hacia-adentro".
Siguiendo esta decisión fundamental, una segunda decisión hecha por el DGC se relaciona con el cómo debe ser especificado el comportamiento deseado. En esta área el DGC escoge usar un formato no completamente formal para especificar el comportamiento. Esto se toma prestado de las especificaciones de la historia de usuario, específicamente del campo de análisis y diseño orientado a objetos. El DGC especifica que los analistas de negocios y los desarrolladores deben colaborar en esta área y además deben señalar el comportamiento en términos de las historias de usuario, las cuales son escritas explícitamente en un documento dedicado. Cada historia de usuario, de alguna forma, debe seguir la siguiente estructura de seguimiento:
El DGC no tiene requerimientos formales para describir exactamente cómo estas historias de usuario deben ser escritas, pero sí insiste en que cada equipo utilizando el DGC declare un formato simple y estandarizado para escribir las historias de usuario, el cual incluye los elementos listados arriba. Sin embargo, en 2007 Dan North sugirió una plantilla para un formato textual, la cual ha encontrado amplio seguimiento en diferentes herramientas DGC de software. Un pequeño ejemplo de este formato puede verse así:
Los escenarios están idealmente expresados de una forma declarativa en lugar de imperativa -- en el lenguaje del negocio, sin referencia a los elementos de la UI, a través de la cual las interacciones ocurren.
Este formato es conocido como el lenguaje Gherkin, que tiene una sintaxis similar al ejemplo de arriba. El término Gherkin, sin embargo, es único para las herramientas de software Cucumber, JBehave y Behat.
El desarrollo guiado por el comportamiento toma prestado el concepto de lenguaje ubicuo del diseño guiado por el dominio. Un lenguaje ubicuo es un lenguaje semiformal compartido por todos los miembros de un equipo de desarrollo de software -- tanto desarrolladores de software como personal no técnico. El lenguaje en cuestión es usado y desarrollado por todos los miembros del equipo para ser un medio común para la discusión del dominio del software en cuestión. De esta forma el DGC se convierte en un vehículo para la comunicación entre todos los roles diferentes en un proyecto de software.
Un riesgo común con el desarrollo de software incluye fallos en la comunicación entre desarrolladores y partes interesadas en el negocio (inversores). El DGC usa la especificación del comportamiento deseado como un lenguaje ubicuo para los miembros del equipo del proyecto. Esta es la razón de que el DGC insiste en usar un lenguaje semiformal para la especificación del comportamiento: sólo un poco de formalidad es un requerimiento para ser un lenguaje ubicuo. Asimismo, tener tal lenguaje crea un modelo de dominio de especificaciones, para que así las especificaciones puedan ser reflexionadas formalmente. Este modelo es también base para las diferentes herramientas de software disponibles que usan DGC.
El ejemplo dado arriba establece una historia de usuario para un sistema de software en desarrollo. Esta historia identifica a la parte interesada, un efecto de negocio y valor de negocio. Asimismo describe varios escenarios, cada uno con una precondición, un detonador y un resultado esperado. Cada una de estas partes está definida exactamente por la parte más formal del lenguaje (el término Dado que puede considerarse como una palabra clave, por ejemplo) y por tal causa es posible que sea procesada de alguna manera por una herramienta que entienda las partes formales del lenguaje ubicuo.
Muy parecido a lo que es la práctica del diseño guiado por pruebas, el DGC asume el uso de utillaje de asistencia especializada en un proyecto. Por más que el DGC sea, en muchos aspectos, una versión más específica del DGP, el utillaje para DGC es similar al de DGP, pero le hace más demandas al desarrollador que el utillaje básico de DGP.[aclaración requerida][cita requerida]
En principio una herramienta de soporte DGC es un armazón para probar software, similar a las herramientas que asisten al DGP. Sin embargo, donde las herramientas DGP tienden a ser libres de formato referente a lo que se permite para pruebas de especificación, las herramientas DGC están relacionadas con la definición del lenguaje ubicuo discutida anteriormente.
Como se mencionó, el lenguaje ubicuo permite a los analistas de negocios el escribir requerimientos de comportamiento de tal forma que los desarrolladores lo puedan entender. El principio del utillaje de asistencia DGC es el convertir estos documentos de requerimientos directamente ejecutables en una colección de pruebas. La implementación exacta de esto varía por cada herramienta, pero la práctica ágil ha presentado el proceso general siguiente:
Dan North ha desarrollado un número de armazones que apoyan el uso del DGC (incluyendo JBehave y RBehave), cuya operación se basa en la plantilla que él sugirió para recopilar historias de usuarios. Estas herramientas usan una descripción textual para casos de uso y varias otras herramientas (como CBehave). Sin embargo, este formato no es requerido y por lo tanto hay otras herramientas que usan otros formatos también. Por ejemplo Fitnesse (que se construyó alrededor de tablas de decisión), también se ha usado para desplegar DGC.
Existen varios ejemplos diferentes del utillaje de software de DGC para uso en proyectos hoy en día, para distintas plataformas y lenguajes de programación.
Posiblemente el más conocido es JBehave, que fue desarrollado por Dan North. El siguiente es un ejemplo tomado de ese proyecto:
Considere una implementación del Juego de la vida. Un experto en dominios (o analista de negocios) tal vez quiera especificar lo que deba pasar cuando alguien prepara una configuración de inicio en la red del juego. Para lograr esto, él tal vez quiera dar un ejemplo del número de pasos dados por una persona que está cambiando de celdas. Saltándonos la parte narrativa, él tal vez haga esto al escribir el siguiente escenario en un documento de texto común y corriente (que es el tipo de documento de ingreso que JBehave lee):
Las palabras resaltadas no son parte de la entrada; se incluye aquí para mostrar cuáles palabras se distinguen como lenguaje formal. JBehave reconoce los términos Dado que (como precondición que define el inicio de un escenario). Cuando (como un detonador) y Entonces (como una pos-condición que debe ser verificada como el resultado de la acción que le sigue al detonador). Basado en esto, JBehave es capaz de leer el archivo de texto que contiene el escenario y de hacer un análisis sintáctico para convertirlo en cláusulas (una cláusula de preparación y después tres detonadores de eventos con condiciones verificables). JBehave después toma estas cláusulas y las pasa a código que es capaz de preparar una prueba, respondiendo a los detonadores de eventos y verificando el resultado. Este código debe estar escrito por los desarrolladores en el equipo del proyecto (en Java, porque esa es la plataforma en que se basa JBehave). En este caso, el código puede verse así:
El código tiene un método para cada tipo de cláusula en un escenario. JBehave identificará cuál método va con cuál cláusula a través del uso de anotaciones y podrá llamar a cada método en orden mientras corre el escenario. El texto en cada cláusula en el escenario tiene que ser el mismo al de la plantilla de texto dada en el código para esa cláusula (por ejemplo, a Dado que en un escenario debe seguir una cláusula de la forma "juego X por Y"). JBehave espera la coincidencia de cláusulas con plantillas y tiene integrado el apoyo para escoger términos de la plantilla y pasarlos a los métodos en el código de prueba como parámetros. El código de prueba provee la implementación para cada tipo de cláusula en un escenario, la cual interactúa con el código que está siendo probado y lleva a cabo una prueba basada en el escenario. En este caso:
La función primaria de este código es el ser un puente entre un archivo de texto con una historia y el código en sí que se está probando. Cabe recalcar que el código de prueba tiene acceso al código que está siendo probado (en este caso una instancia del Juego) y es muy simple en su naturaleza. El código de prueba tiene que ser simple, ya que de otra forma un desarrollador terminaría escribiendo pruebas para sus pruebas.
Finalmente, para logar correr las pruebas, JBehave requiere de un poco de "código de plomería" que identificará los archivos de texto que contienen escenarios y que agregan dependencias (como instancias de Juego) dentro del código de prueba. Este código de plomería no está ilustrado aquí, ya que es un requerimiento técnico de JBehave y no se relaciona directamente al estilo principal del estilo de prueba DGC.
Una subcategoría separada del desarrollo guiado por el comportamiento es formada por herramientas que usan especificaciones como un lenguaje de entrada en lugar de usar historias. Un ejemplo de este estilo es la herramienta RSpec, que también fue desarrollada por Dan North. Las herramientas de especificación no utilizan historias de usuario como un formato de entrada para probar escenarios, sino que usan especificaciones funcionales para unidades que están siendo probadas. Estas especificaciones frecuentemente tienen una naturaleza más técnica que las historias de usuario y además son usualmente menos convenientes para la comunicación entre personal de negocios que las historias de usuario. Un ejemplo de una especificación para una pila podría verse así:
Tal especificación puede especificar exactamente el comportamiento que se está probando, pero tiene mayor insignificancia para un usuario de negocios (inversionistas por ejemplo). Como resultado, las pruebas guiadas por la especificación aparecen en la práctica del DGC como un complemento a las pruebas guiadas por historias y operan a un menor nivel. Las pruebas de especificación son a veces vistas como un reemplazo para las pruebas unitarias con formato libre.
Las herramientas de pruebas de especificación como RSpec y JDave son un tanto diferentes en naturaleza a otras como JBehave. Debido a que son vistas como alternativas a las herramientas básicas de pruebas unitarias como JUnit, estas herramientas tienden a favorecer el abstenerse a la separación de la historia y el probar código, en su lugar 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í:
Este ejemplo muestra una especificación en un lenguaje legible incrustado en código ejecutable. En este caso se escoge una herramienta para formalizar el lenguaje de especificación y meterlo en el lenguaje de código de prueba al agregar los métodos llamados (eso) it y (debería) should. Asimismo existe un concepto de una pre-condición para la especificación -- la sección (antes) before establece las pre-condiciones en las que se basa la especificación.
Los resultados de la prueba serán:
Escribe un comentario o lo que quieras sobre Desarrollo guiado por comportamiento (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)