Behavior

Driven
Development:
Transformando
la Prueba de
Software
Un Enfoque Colaborativo
desde la Perspectiva del
Equipo de Pruebas

Omar S. Guzmán
 Nombre:

Omar S. Guzmán

Matrícula:

2022-0866

Asignatura:

Administración de proyectos

Docente:

Francisco Genao

Tema:

Behavior Driven Development (BDD)

Fecha:

08/08/2024

Institución:

Instituto Tecnológico de las Américas (ITLA)

1
ÍNDICE

Contenido
Concepto ................................................................................................................................................... 4
Beneficios y funciones .............................................................................................................................. 4
1. Feature Files (Archivos de Características) ....................................................................................... 6
2. Step Definitions (Definiciones de Pasos) .......................................................................................... 6
3. Runner Scripts (Scripts de Ejecución) ............................................................................................... 7
Cucumber .................................................................................................................................................. 8
SpecFlow ................................................................................................................................................... 9
Behat ....................................................................................................................................................... 10
JBehave ................................................................................................................................................... 12
Gatling (para pruebas de rendimiento BDD) .......................................................................................... 13

2
INTRODUCCIÓN

¿Qué lenguaje utilizaremos para obtener los requerimientos del cliente? Si tenemos un
problema técnico, ¿qué palabras usaremos para dejar claro lo que sucede sin utilizar
expresiones difíciles? ¿Cómo comunicaremos nuestro avance a una persona interesada que
tiene poco o ningún conocimiento de tecnología? A principios del 2000, los equipos de
desarrollo de software empezaron a encontrarse cada vez más con estas preguntas. El enfoque
tradicional de pruebas unitarias, aunque esencial, ya no era suficiente para asegurar que el
producto final reflejara correctamente los requisitos del cliente.

En los primeros años del siglo XXI, la industria del software se encontraba en una fase de
evolución rápida. Las metodologías ágiles empezaban a ganar popularidad, y con ellas, surgía
una mayor conciencia sobre la importancia de la colaboración efectiva y la comunicación clara
en los equipos de desarrollo. A pesar de los avances, muchos proyectos aún fracasaban debido
a malentendidos en los requisitos del cliente y la falta de alineación entre las expectativas de
los interesados y los entregables del equipo técnico. Los equipos de pruebas necesitaban una
manera de validar que el software se comportara como se esperaba en escenarios reales de
uso. Esto implicaba una transición de la simple verificación de código a una validación más
holística, donde los comportamientos del sistema fueran definidos claramente desde el
principio, alineándose con los deseos y necesidades del usuario. Esta transición no solo
mejoraría la calidad del software, sino que también fortalecería la comunicación dentro del
equipo y con los stakeholders, asegurando que todos compartieran la misma visión del
producto final.

Para abordar este desafío, surgió un enfoque que permitía a los equipos de pruebas definir,
implementar y verificar los comportamientos esperados del sistema desde una perspectiva de
usuario. Esta metodología no solo cerraba la brecha entre el equipo de pruebas, los
desarrolladores y los clientes, sino que también permitía una mayor alineación en torno a los
objetivos del proyecto, garantizando que el software entregado cumpliera con las expectativas
del usuario final.

3
¿Que es BDD?

Concepto

Behavior Driven Development (Desarrollo Guiado por Comportamiento, en español) es un

enfoque centrado en describir el comportamiento esperado del software desde la perspectiva
del usuario final. Este enfoque se basa en la premisa de que todos los miembros del equipo,
incluyendo desarrolladores, testers y stakeholders, pueden entender y contribuir a la definición
de los comportamientos deseados del sistema. Su propio creador, Dan North, dice que BDD
implica hasta la implementación de la aplicación o sistema que desarrollamos basándose solo
en historias de usuario.

Pero, puede que alguien se pregunte ¿qué tenían de malo los test? La respuesta es nada, pero
hacía falta una mejor garantía de que se está desarrollando lo que el cliente pidió. El mismo
Dan North asegura que utiliza más la palabra “comportamiento” que “prueba”. Esto nos deja
un principio moderno del desarrollo: los métodos de prueba no describen de forma exacta el
comportamiento de una aplicación. El desarrollo se vuelve mucho más sencillo cuando
pensamos en acciones que ejecuta el sistema y no en un test. North dice: “¿Cómo llamar a tu
prueba? Es fácil: es una oración que describe el siguiente comportamiento en el que estás
interesado. ¿Cuánto probar? Se vuelve irrelevante: solo puedes describir cierto
comportamiento en una sola oración”. Y añade: “Cuando una prueba falla, simplemente sigue
el proceso descrito anteriormente: o introdujiste un error, el comportamiento cambió o la
prueba ya no es relevante” (North, 2006).

Beneficios y funciones

Las especificaciones de BDD se escriben en un lenguaje natural y accesible, a menudo utilizando

el formato Given-When-Then. Este formato permite que cualquier persona involucrada en el
proyecto, independientemente de su conocimiento técnico, pueda comprender y verificar los
requisitos del sistema. Los autores Carlos Solís y Xiaofeng Wang explican: “[BDD] permite que
los clientes y desarrolladores hablen el mismo idioma sin ambigüedad” (Solís & Wang, 2011). En
adición, BDD fomenta la colaboración entre desarrolladores, testers y stakeholders desde el

4
inicio del proyecto. Las discusiones sobre el comportamiento esperado del sistema ayudan a
asegurar que todos los miembros del equipo tengan un entendimiento compartido de los
requisitos.

Además de lo anterior, BDD ofrece beneficios en términos de eficiencia temporal. Los

escenarios de BDD se transforman en pruebas automatizadas, lo que no solo asegura que las
funcionalidades del software se comporten según lo esperado, sino que también ayuda
significativamente a reducir los errores de regresión. Estos escenarios, escritos en un lenguaje
accesible y orientado al negocio, funcionan como una documentación viva del sistema. Esto no
solo facilita la comprensión inicial del software, sino que también simplifica su mantenimiento
continuo a lo largo del tiempo.

Actualmente, el Desarrollo Guiado por Comportamiento (BDD) está relacionado con las
metodologías ágiles, especialmente Desarrollo Guiado por Pruebas (TDD) y el Diseño Guiado
por el Dominio (DDD). Aunque BDD surgió de TDD, lo cierto es que ha resultado más eficiente
en el manejo de proyectos con requisitos cambiantes. Cierto autor inglés asegura que BDD se
ajusta tan bien a la realidad que sigue el principio que dice “Cuando el terreno no concuerda
con el mapa, confía en el terreno” (Ferguson, 2014). Así que, BDD nos ayuda a comprender lo
que tenemos que desarrollar de una manera más profunda que cualquier plan o prueba.

5
Partes de BDD

Algunos de los componentes clave de BDD son:

1. Feature Files (Archivos de Características):

Los archivos de características son documentos que contienen los escenarios de BDD
escritos en un lenguaje simple y comprensible. Estos archivos se estructuran en un
formato Given-When-Then, que ayuda a describir el comportamiento del sistema de
manera clara y accesible. Cada escenario en un archivo de características representa
una funcionalidad específica del sistema y está diseñado para ser fácilmente entendible
tanto por los desarrolladores como por los stakeholders. El formato Given-When-Then
se descompone de la siguiente manera:

o Given (Dado que): Describe el estado inicial o el contexto en el que se encuentra

el sistema antes de que ocurra el evento.

o When (Cuando): Define la acción o el evento que se está realizando en el

sistema.

o Then (Entonces): Expone el resultado esperado o el comportamiento que debe

observarse después de que la acción se haya llevado a cabo.

2. Step Definitions (Definiciones de Pasos):

Las definiciones de pasos actúan como el puente entre los escenarios escritos en los
archivos de características y el código de prueba que se ejecuta. En este componente, se
implementan las acciones y verificaciones especificadas en los escenarios. Cada paso en
un escenario tiene una definición correspondiente en el código, donde se especifica
cómo realizar la acción o comprobación descrita en el archivo de características. Esto
permite que el lenguaje natural utilizado en los escenarios se traduzca en código
ejecutable que interactúa con la aplicación o sistema bajo prueba. Las definiciones de
pasos facilitan la integración entre el comportamiento esperado y la implementación
real, asegurando que las pruebas sean precisas y útiles.

6
 3. Runner Scripts (Scripts de Ejecución):

Los scripts de ejecución son responsables de coordinar la ejecución de las pruebas

automáticas. Estos scripts vinculan los escenarios descritos en los archivos de
características con las definiciones de pasos correspondientes y los ejecutan en el
entorno de prueba adecuado. Los runner scripts se encargan de configurar el entorno
de prueba, ejecutar las pruebas en el orden correcto y reportar los resultados de
manera estructurada. Además, facilitan la integración con herramientas de
automatización de pruebas y marcos de pruebas, permitiendo la ejecución continua y la
integración continua de pruebas en el proceso de desarrollo.

Estos componentes trabajan juntos para proporcionar un enfoque estructurado y efectivo para
la prueba de software basado en el comportamiento esperado del sistema. Al utilizar BDD, los
equipos pueden garantizar que el software cumpla con las expectativas del usuario final y que
todos los miembros del equipo compartan una comprensión común de los requisitos del
proyecto.

7
Herramientas de BDD y ejemplos

El Desarrollo Guiado por Comportamiento (BDD) es un enfoque que mejora la colaboración

entre los desarrolladores y los stakeholders mediante la definición de escenarios de
comportamiento en un lenguaje natural. Existen diversas herramientas que facilitan la
implementación de BDD en distintos entornos de desarrollo. A continuación, se describen
algunas de las herramientas más populares, sus características principales y ejemplos de uso.

Cucumber

Cucumber es una herramienta de BDD ampliamente utilizada que permite escribir escenarios
de pruebas en un lenguaje legible por humanos, utilizando el formato Gherkin. Cucumber se
integra con múltiples lenguajes de programación y es compatible con diversas herramientas de
automatización.

Ejemplo de uso:

 Feature File (Archivo de Características):

Feature: Transferencia de fondos

Scenario: Transferir fondos a una cuenta local

Given tengo una cuenta con $100

When transfiero $50 a una cuenta local

Then mi cuenta debe tener $50

 Step Definitions (Definiciones de Pasos en Java):

@Given("tengo una cuenta con ${int}")

public void tengo_una_cuenta_con(int cantidad) {

8
 // Implementación para crear una cuenta con la cantidad especificada

@When("transfiero ${int} a una cuenta local")

public void transfiero_a_una_cuenta_local(int cantidad) {

// Implementación para transferir la cantidad a una cuenta local

@Then("mi cuenta debe tener ${int}")

public void mi_cuenta_debe_tener(int cantidad) {

// Implementación para verificar el saldo de la cuenta

SpecFlow

SpecFlow es una herramienta de BDD para el ecosistema .NET. Permite escribir escenarios en el
formato Gherkin y se integra estrechamente con herramientas de pruebas de .NET como NUnit
y MSTest.

Ejemplo de uso:

 Feature File (Archivo de Características):

Feature: Login de usuario

Scenario: Usuario inicia sesión con credenciales válidas

Given el usuario está en la página de inicio de sesión

When el usuario ingresa su nombre de usuario y contraseña

Then el usuario debe ser redirigido a su página de inicio

9
  Step Definitions (Definiciones de Pasos en C#):

[Given(@"el usuario está en la página de inicio de sesión")]

public void DadoElUsuarioEstaEnLaPaginaDeInicioDeSesion() {

// Implementación para abrir la página de inicio de sesión

[When(@"el usuario ingresa su nombre de usuario y contraseña")]

public void CuandoElUsuarioIngresaSuNombreDeUsuarioYContrasena() {

// Implementación para ingresar las credenciales del usuario

[Then(@"el usuario debe ser redirigido a su página de inicio")]

public void EntoncesElUsuarioDebeSerRedirigidoASuPaginaDeInicio() {

// Implementación para verificar la redirección del usuario

Behat

Behat es una herramienta de BDD para PHP que permite definir escenarios en lenguaje
Gherkin. Está diseñada para trabajar con el ecosistema de PHP y facilita la integración con
frameworks de pruebas y automatización.

10
Ejemplo de uso:

 Feature File (Archivo de Características):

Feature: Registro de usuario

Scenario: Usuario se registra con éxito

Given el usuario está en la página de registro

When el usuario completa el formulario de registro

Then el usuario debe ver un mensaje de confirmación

 Step Definitions (Definiciones de Pasos en PHP):

/** @Given el usuario está en la página de registro */

public function elUsuarioEstaEnLaPaginaDeRegistro() {

// Implementación para abrir la página de registro

/** @When el usuario completa el formulario de registro */

public function elUsuarioCompletaElFormularioDeRegistro() {

// Implementación para completar el formulario de registro

/** @Then el usuario debe ver un mensaje de confirmación */

public function elUsuarioDebeVerUnMensajeDeConfirmacion() {

// Implementación para verificar el mensaje de confirmación

11
JBehave

JBehave es una herramienta de BDD para Java que permite escribir escenarios en lenguaje
natural. Es conocida por su flexibilidad y su capacidad para integrar pruebas de
comportamiento en aplicaciones Java.

Ejemplo de uso:

 Story File (Archivo de Historias):

Scenario: Crear una nueva cuenta

Given I am on the account creation page

When I submit the account creation form

Then I should see a confirmation message

 Step Definitions (Definiciones de Pasos en Java):

@Given("I am on the account creation page")

public void givenIAmOnTheAccountCreationPage() {

// Implementación para navegar a la página de creación de cuenta

@When("I submit the account creation form")

public void whenISubmitTheAccountCreationForm() {

// Implementación para enviar el formulario de creación de cuenta

@Then("I should see a confirmation message")

public void thenIShouldSeeAConfirmationMessage() {

// Implementación para verificar el mensaje de confirmación

12
}

Gatling (para pruebas de rendimiento BDD)

Gatling es una herramienta para pruebas de rendimiento que también puede utilizarse con un
enfoque BDD para describir escenarios de carga y rendimiento.

Ejemplo de uso:

 Scenario File (Archivo de Escenarios):

val scn = scenario("Prueba de rendimiento")

.exec(http("Request")

.get("/home")

.check([Link](200)))

 Runner Script (Script de Ejecución en Scala):

setUp(

[Link](atOnceUsers(100))

).protocols(httpProtocol)

Cada una de estas herramientas ofrece una manera única de implementar BDD en diferentes
lenguajes y entornos. Al elegir la herramienta adecuada, los equipos pueden mejorar la
comunicación entre los miembros del proyecto, garantizar que el software cumpla con los
requisitos del usuario y automatizar las pruebas de manera efectiva.

13
Conclusion

El Desarrollo Guiado por Comportamiento (BDD) ha emergido como una metodología crucial en
el ámbito del desarrollo de software moderno, especialmente en el contexto de las
metodologías ágiles. Su enfoque en la colaboración y la comunicación clara entre todos los
miembros del equipo, así como con los stakeholders, ha demostrado ser fundamental para el
éxito de los proyectos de software.

A lo largo de este trabajo, se ha destacado que BDD se basa en la premisa de describir el

comportamiento esperado del software desde la perspectiva del usuario final. Esta metodología
no solo mejora la claridad de los requisitos, sino que también facilita una mejor alineación entre
los objetivos del negocio y el desarrollo técnico. La utilización de un lenguaje natural para
definir escenarios de comportamiento permite que tanto los desarrolladores como los
stakeholders tengan una comprensión compartida y accesible de los requisitos del sistema.

Los componentes clave de BDD, como los Feature Files, Step Definitions y Runner Scripts,
juegan un papel fundamental en la implementación efectiva de esta metodología. Los Feature
Files proporcionan una forma estructurada y comprensible de definir los comportamientos del
sistema, mientras que las Step Definitions conectan estos comportamientos con el código de
prueba ejecutable. Los Runner Scripts coordinan la ejecución de las pruebas, asegurando que se
realicen en el entorno adecuado y facilitando la integración continua.

Las herramientas de BDD, como Cucumber, SpecFlow, Behat, JBehave y Gatling, ofrecen
diversas opciones para implementar BDD en distintos entornos de desarrollo y lenguajes de
programación. Cada herramienta tiene sus propias características y ventajas, adaptándose a
diferentes necesidades y preferencias. Por ejemplo, Cucumber y SpecFlow son altamente
valorados en sus respectivos ecosistemas de Ruby y .NET, mientras que Behat es una opción
destacada para PHP y JBehave para Java. Gatling, aunque orientada a pruebas de rendimiento,
también aplica el enfoque BDD para describir escenarios de carga.

En conclusión, el enfoque BDD no solo contribuye a la creación de software de alta calidad al

asegurar que el sistema cumpla con las expectativas del usuario final, sino que también
fortalece la colaboración y la comunicación dentro del equipo de desarrollo. La adopción de
BDD y sus herramientas asociadas representa un avance significativo en la forma en que los
equipos de desarrollo abordan el diseño, la implementación y la prueba del software, alineando
de manera más efectiva los entregables con los objetivos del negocio y las necesidades del
usuario.

14
Este enfoque continúa evolucionando y adaptándose a las demandas cambiantes del desarrollo
de software, reafirmando su relevancia y utilidad en la creación de soluciones efectivas y bien
alineadas con las expectativas de los usuarios finales.

Referencias

 Ferguson Smart, J. (2014). BDD In Action. Behavior-Driven Development For The Whole
Software Lifecycle. Recuperado el 08 de agosto de 2024, de [Link]
[Link]/download/a/bdba704-bf94-4c86-ac9a-
a8c9353bee14/BDD_CH01.pdf

 North, D. (2006, septiembre 20). Introducing BDD. En Dan North & Associates Limited.
Recuperado el 08 de agosto de 2024, de [Link]

 Solís, C., Wang, X. (2011). A Study of the Characteristics of Behaviour Driven

Development. Universidad de Limerick, Irlanda. Recuperado el 08 de agosto de 2024, de
[Link]
racteristics%20of%20Behaviour%20Driven%[Link]

15