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 orientado 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.
El BDD se facilita en gran medida mediante el uso de un lenguaje simple de dominio específico (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]
Historia
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.
BDD se centra en:
- Dónde empezar en el proceso
- Qué probar y qué no probar
- Cuánto probar de una vez
- Como llamar a las pruebas
- Cómo entender por qué falla una prueba
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:
BDD es una metodología ágil de segunda generación, de afuera hacia adentro, basada en extracción, de múltiples partes interesadas, de múltiples escalas, de alta automatización. Describe un ciclo de interacciones con salidas bien definidas, lo que da como resultado la entrega de software probado y funcional que importa.
Durante una entrevista con Dan North en la Conferencia GOTO en 2013, Liz Keogh [12] definió BDD como:
Es 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 "The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends". El primer marco basado en historias en RSpec fue reemplazado más tarde por Cucumber, desarrollado principalmente por Aslak Hellesøy . Capybara , que forma parte del marco de pruebas de Cucumber, es uno de esos programas de automatización de pruebas basados en la web.
Principios de BDD
El desarrollo impulsado por pruebas es una metodología de desarrollo de software que esencialmente establece que para cada unidad de software, un desarrollador de software debe:
- primero defina un conjunto de prueba para la unidad ;
- hacer que las pruebas fallen;
- luego implemente la unidad;
- finalmente verificar que la implementación de la unidad hace que las pruebas sean exitosas.
Esta definición es bastante inespecífica ya que permite pruebas en términos de requisitos de software de alto nivel, detalles técnicos de bajo nivel o cualquier cosa intermedia. Por lo tanto, una forma de ver BDD es que es un desarrollo continuo de TDD que hace elecciones más específicas que TDD.
El desarrollo impulsado por 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]
Especificaciones de comportamiento
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 opta por utilizar un formato semiformal para la especificación del comportamiento que se toma prestado de las especificaciones de la historia del 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 de las unidades de software utilizando el lenguaje específico del dominio de la situación.
BDD especifica que los analistas de negocios y los desarrolladores deben colaborar en esta área y deben especificar el comportamiento en términos de historias de usuarios, cada una de las cuales está explícitamente escrita en un documento dedicado. [1] [16] Cada historia de usuario debe, de alguna manera, seguir la siguiente estructura: [5] [16]
- Título
- Un título explícito.
- Narrativa
- Una pequeña sección introductoria con la siguiente estructura:
- Como : la persona o función que se beneficiará de la función;
- Quiero : la característica;
- de modo que : el beneficio o el valor de la función.
- 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;
- Luego : el resultado esperado, en una o más cláusulas.
BDD no tiene ningún requisito formal sobre cómo deben escribirse exactamente estas historias de usuario, pero insiste en que cada equipo que usa 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 amplio 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 intercambien, para poder realizar un seguimiento del inventario.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 inventario, cuando devuelvan el suéter negro para un reembolso, entonces debería tener cuatro suéteres negros en inventario.Escenario 2: Los artículos intercambiados deben devolverse al inventario.Dado que un cliente me compró previamente una prenda azul y tengo dos prendas azules en inventario y tres prendas negras en inventario, cuando cambien la prenda azul por una 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 en lugar de imperativa, en el lenguaje empresarial, sin referencia a los elementos de la interfaz de usuario a través de los cuales tienen lugar las interacciones. [17]
Este formato se conoce como el lenguaje Gherkin, que 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] behave y Behat . [19] [20] [21] [22]
La especificación como lengua ubicua
El desarrollo impulsado por el comportamiento toma prestado el concepto del lenguaje ubicuo del diseño impulsado por el dominio . [5] [7] Un lenguaje ubicuo es un lenguaje (semi) formal que es compartido por 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 todos los roles diferentes en un proyecto de software. [5] [24]
Un riesgo común con el desarrollo de software incluye fallas en la comunicación entre los desarrolladores y las partes interesadas del negocio. [25] BDD usa 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, por lo que las especificaciones pueden razonarse formalmente. [26] Este modelo también es la base para las diferentes herramientas de software compatibles con 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 a 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 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]
Soporte de herramientas especializado
Al igual que la práctica del diseño basado en pruebas, el desarrollo basado en el 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 por 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 BDD sea un poco más laborioso para trabajar como desarrollador, 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" ).
Principios de herramientas
En principio, una herramienta de soporte BDD es un marco de prueba para software, al igual que las herramientas que admiten TDD. Sin embargo, donde 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 discutió, el lenguaje ubicuo permite a los analistas de negocios escribir los requisitos de comportamiento de una manera que los desarrolladores también entenderán. El principio de las herramientas de soporte de BDD es hacer que estos mismos documentos de requisitos se puedan ejecutar directamente 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 generado el siguiente proceso general:
- La herramienta lee un documento de especificaciones.
- Las herramientas comprenden directamente partes completamente formales del lenguaje ubicuo (como la palabra clave Given en el ejemplo anterior). En base a esto, la herramienta divide cada escenario en cláusulas significativas.
- Cada cláusula individual en un escenario se transforma en algún tipo de parámetro para una prueba de la historia del 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.
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 grabar historias de usuarios. [5] Estas herramientas utilizan una descripción textual para 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]
Ejemplos de herramientas
Hay varios ejemplos diferentes de herramientas de software BDD en uso en proyectos hoy en día, para diferentes plataformas y lenguajes de programación.
Posiblemente el más conocido es JBehave, que fue desarrollado por Dan North, Elizabeth Keogh y varios otros. [30] El siguiente es un ejemplo tomado de ese proyecto: [20]
Considere 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 está configurando una configuración inicial de la cuadrícula del juego. Para hacer esto, es posible que desee dar un ejemplo de una serie de pasos dados por una persona que está alternando células. Omitiendo la parte narrativa, podría hacerlo escribiendo el siguiente escenario en un documento de texto sin formato (que es el tipo de documento de entrada que lee JBehave):
Dado un juego de 5 por 5 Cuando alterno la celda en (3, 2) Entonces la cuadrícula debería verse como.................X.......Cuando i Mueva la celda en (3, 1) A continuación, la red debe ser similar.................X....X..Cuando i Mueva la celda en (3, 2) A continuación, la red debe ser similar......................X..
La letra en negrita no es 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 condición posterior 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). JBehave luego toma estas cláusulas y las pasa al código que es capaz de establecer una prueba, responder a los desencadenantes del evento 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 de juego privado ; renderizador de 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 ); }@Entonces ( "la cuadrícula debe verse como $ cuadrícula" ) public void theGridShouldLookLike ( String grid ) { assertThat ( renderizador . AsString (), equalTo ( cuadrícula )); }
El código tiene un método para cada tipo de cláusula en un escenario. JBehave identificará qué método va con qué cláusula mediante el uso de anotaciones y llamará a cada método en orden mientras se ejecuta en el escenario. Se espera que el texto de cada cláusula en el escenario coincida con el texto de la plantilla proporcionado en el código para esa cláusula (por ejemplo, se espera que un Dado en un escenario vaya seguido de una cláusula de la forma "un juego X por Y") . JBehave admite la coincidencia de cláusulas con plantillas y tiene soporte incorporado 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:
- El
theGameIsRunning
método reacciona a una cláusula dada configurando la cuadrícula del juego inicial. - El
iToggleTheCellAt
método reacciona a una cláusula When activando el evento toggle descrito en la cláusula. - El
theGridShouldLookLike
mé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 las pruebas de estilo BDD.
Historia versus especificación
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 usuario como formato de entrada para escenarios de prueba, sino que utilizan especificaciones funcionales para las unidades que se están probando. Estas especificaciones a menudo tienen una naturaleza más técnica que las historias de usuarios y, por lo general, son menos convenientes para la comunicación con el personal comercial que las historias de usuarios. [5] [31] Un ejemplo de una 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 pilaCuando 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
Tal especificación puede especificar exactamente 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 de las pruebas basadas en historias y funcionan en un nivel inferior. Las pruebas de especificación 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 algo diferentes en su naturaleza a herramientas como JBehave. Dado que se ven como 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 do let ( : hash ) { Hash [ : hola , 'mundo' ] } it { espera ( Hash . nuevo ) . a eq ({}) } que "codifica la información correcta de una tecla" no esperar ( de hash [ hello ] ) . al final de eq ( 'mundo' ) que 'incluye clave' hacer picadillo . llaves . ¿incluir? ( : hola ) . debe ser verdadero fin fin
Este ejemplo muestra una especificación en lenguaje legible incrustado 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 llamados it
y should
. También existe el concepto de una condición previa de especificación: la before
secció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 hash la información correcta en una clave
Los tres amigos
Los Tres Amigos, también conocido como un "Taller de Especificación", es una reunión en la que el Propietario del Producto discute el requisito en forma de Especificación por Ejemplo con diferentes partes interesadas como el equipo de QA y desarrollo. El objetivo clave de esta discusión es iniciar una conversación e identificar cualquier especificación que falte. La discusión también brinda una plataforma para que QA, el equipo de desarrollo y el propietario del producto converjan y escuchen la perspectiva de los demás para enriquecer el requisito y también asegurarse de que están construyendo el producto correcto. [33]
Los tres amigos son
- Negocios: la función del usuario comercial es definir solo el problema (y no aventurarse a sugerir ninguna 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 de 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.
Ver también
- Especificación por ejemplo
- Behat (marco PHP)
- Marco de Cynefin
- Concordion (marco de Java)
- Calibre (software)
- Jasmine (marco de prueba de JavaScript)
- Squish GUI Tester (herramienta de prueba BDD GUI para JavaScript, Python, Perl, Ruby y Tcl)
- Caso de uso
Referencias
- ↑ a b c d e North, Dan (marzo de 2006). "Presentación de BDD" . Dan North . Consultado el 25 de abril de 2019 .
- ^ a b c "Desarrollo impulsado por el comportamiento" . Archivado desde el original el 1 de septiembre de 2015 . Consultado el 12 de agosto de 2012 .
- ^ Keogh, Liz (7 de septiembre de 2009). "Introducción al desarrollo impulsado por el comportamiento" . SkillsMatter . Consultado el 1 de mayo de 2019 .
- ^ John Ferguson Smart (2014). BDD en acción: desarrollo basado en el comportamiento para todo el ciclo de vida del software . Publicaciones Manning. ISBN 9781617291654.
- ^ a b c d e f g h yo j k Haring, Ronald (febrero de 2011). de Ruiter, Robert (ed.). "Desarrollo impulsado por el comportamiento: mejor desarrollo impulsado por la prueba dan". Revista Java (en holandés). Revistas Veen (1): 14-17. ISSN 1571-6236 .
- ^ Solís, Carlos; Wang, Xiaofeng (2011). "Un estudio de las características del desarrollo impulsado por la conducta". Ingeniería de software y aplicaciones avanzadas (SEAA), 2011 37ª Conferencia EUROMICRO en : 383–387. doi : 10.1109 / SEAA.2011.76 . hdl : 10344/1256 . ISBN 978-1-4577-1027-8.
- ^ a b c d Bellware, Scott (junio de 2008). "Desarrollo impulsado por el comportamiento" . Revista Code . Archivado desde el original el 12 de julio de 2012 . Consultado el 1 de mayo de 2019 .
- ^ Tharayil, Ranjith (15 de febrero de 2016). "Desarrollo impulsado por el comportamiento: simplificar el espacio de problemas complejos" . SolutionsIQ . Consultado el 15 de febrero de 2018 .
- ^ Liz Keogh (27 de junio de 2011). "ATDD vs. BDD, y una historia en maceta de algunas cosas relacionadas" . Consultado el 6 de mayo de 2019 .
- ^ "El libro RSpec - Pregunta sobre el capítulo 11: software de escritura que importa" . Archivado desde el original el 7 de noviembre de 2009 . Consultado el 9 de agosto de 2009 .
- ^ Dan North: Cómo vender BDD a la empresa. Archivado el 25 de noviembre de 2010 en Wayback Machine.
- ^ "Liz Keogh" .
- ^ GOTO 2013 • Entrevista con Liz Keogh y Dan North https://www.youtube.com/watch?v=g5WpUJk8He4
- ^ D.North, presentando RBehave
- ^ S. Miller, InfoQ: RSpec incorpora RBehave
- ^ a b c d e North, Dan (11 de febrero de 2007). "¿Qué hay en una historia?" . Dan North . Consultado el 12 de agosto de 2012 .
- ^ Mabey, Ben. "Escenarios imperativos vs declarativos en historias de usuarios" . Archivado desde el original el 3 de junio de 2010 . Consultado el 19 de mayo de 2008 .
- ^ "Cáscara de nuez - documentación de Lettuce 0.2.23 (liberación de kryptonita)" . lechuga . Consultado el 6 de febrero de 2020 .
- ^ "Pepinillo" . Consultado el 7 de junio de 2020 .
- ^ a b "¿Qué es JBehave?" . JBehave.org . Consultado el 20 de octubre de 2015 .
- ^ "comportarse es un desarrollo impulsado por el comportamiento, estilo Python" . Archivado desde el original el 22 de enero de 2018 . Consultado el 30 de enero de 2018 .
- ^ "Funciones de escritura - documentación de Behat 3.0.12" . behat documentación . Archivado desde el original el 19 de septiembre de 2015 . Consultado el 20 de octubre de 2015 .
- ^ a b Evans, Eric (2003). Diseño basado en dominios: abordar la complejidad en el corazón del software . Addison-Wesley. ISBN 978-0-321-12521-7. Consultado el 12 de agosto de 2012 .
- ^ North, Dan (31 de mayo de 2012). "BDD es como TDD si ..." . organizaciones más rápidas, software más rápido . Dan North y asociados . Consultado el 12 de agosto de 2012 .
- ^ Geneca (16 de marzo de 2011). "Por qué fallan los proyectos de software" . Consultado el 16 de marzo de 2011 .
- ^ Mahmudul Haque Azad (6 de febrero de 2011). "Diga hola al desarrollo impulsado por el comportamiento" . Consultado el 12 de agosto de 2012 .
- ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modelado de casos de prueba en BPMN para el desarrollo impulsado por el comportamiento". Software IEEE . 33 (5): 15-21. doi : 10.1109 / MS.2016.117 .
- ^ Adam Craven (21 de septiembre de 2015). "Fundamentos del desarrollo impulsado por el comportamiento a escala empresarial (BDD)" . Consultado el 14 de enero de 2016 .
- ^ Ketil Jensen (13 de diciembre de 2009). "BDD con tablas de escenarios en Fitnesse Slim" . Camina por el camino . Wordpress . Consultado el 12 de agosto de 2012 .
- ^ "jbehave.org/team-list" . JBehave. 2017-05-28 . Consultado el 1 de mayo de 2019 .
- ^ a b Roy Osherove (4 de octubre de 2008). "BDD: Comportamiento frente a marcos de especificaciones" . Consultado el 12 de agosto de 2012 .
- ^ Jason Seifer (7 de diciembre de 2011). "Una introducción a RSpec" . Consultado el 27 de octubre de 2012 .
- ^ "¿Qué son los Tres Amigos en Ágil?" . Alianza ágil . 2016-06-16 . Consultado el 10 de junio de 2019 .