INTRODUCCIÓN AL DESARROLLO DIRIGIDO POR COMPORTAMIENTO

El Desarrollo Dirigido por Comportamiento (Behavior-driven development o BDD) es una técnica de desarrollo ágil orientada al negocio y comportamiento de una aplicación. Su principal objetivo es preguntar qué debería hacer la aplicación antes y durante el proceso de desarrollo. Esto se consigue mediante tests de comportamiento o especificaciones, que son escritas por los desarrolladores y que a continuación se encargan de implementar.

BDD parte de la práctica de Programación Desarrollo Orientado a Pruebas (TDD) y comparte sus mismas fases:

  • Escribir un test y comprobar qué falla.
  • Desarrollar el mínimo código necesario para que el test pase.
  • Refactorizar.

imagen1

Mientras que TDD se centra en pruebas unitarias, BDD se centra en el comportamiento de la aplicación. Su propósito es definir el comportamiento de la aplicación independientemente de cómo esté implementado. Por ello, BDD y TDD no solo son compatibles, sino que es muy recomendable su uso conjunto.

imagen2

Muchas de las herramientas que permiten adoptar BDD en un proyecto tienen un lenguaje entendible por todas las personas implicadas. Al ser un lenguaje común, BDD se puede usar incluso como parte de documentación y como pruebas de aceptación del proyecto. Además puede permitir que tanto el cliente, jefe de proyecto, analistas, etc., puedan participar con los desarrolladores en la definición o validación de las especificaciones.

¿Por qué usar BDD?

1. Evitar entregar algo no deseado.

Es quizá una de las ventajas más evidentes de esta técnica. El desarrollo parte siempre de especificaciones concretas que definen el comportamiento de lo que se va a implementar a continuación. Si hubiese un cambio de requisitos lo primero que se debe actualizar son las especificaciones que se vean afectadas y, por lo tanto, se comprobará en ese mismo instante si se cumplen o no.

2. Desarrollar sin pensar bien la funcionalidad.

BDD es un buen punto de partida para definir por dónde comenzar un desarrollo. Una vez definida una especificación, los desarrolladores deben tener información completa de qué es lo que deben realizar a continuación y si no es así se debería revisar la especificación o la información con la que se contaba para escribirla.

3. Evitar código no usado.

A la hora de desarrollar la interfaz de un nuevo módulo, nos encontramos muy a menudo que se desarrollan métodos que más tarde nunca son usados. Por ejemplo, nos podemos encontrar que al desarrollar un módulo que trabaje con datos de un repositorio, se nos ocurra que necesitemos métodos para crear, eliminar, modificar, etc. Después de codificar y según avancemos en el desarrollo, nos podemos encontrar que el método de modificar en ese caso concreto no tenía sentido en el negocio concreto de la aplicación. Mediante BDD no se desarrollarían los métodos hasta que no existiese un test, y por tanto una definición que lo necesitase la aplicación.

4. Mejorar los tiempos de desarrollo.

Como consecuencia de los puntos anteriores, BDD permite atacar directamente a los problemas y necesidades del desarrollo actual, aunque por otro lado es una técnica que tiene que madurar el equipo para poder sacar su máximo partido.

Escenario de ejemplo:

imagen3

A continuación os dejo un ejemplo de cómo sería un escenario en BDD con la herramienta SpecFlow para .Net. En este caso queremos desarrollar el login de una aplicación y creamos un escenario en el que introduciríamos credenciales válidas:

Podemos observar los siguientes elementos:

  • Feature: Incluiría una descripción del conjunto de escenarios que incluye.
  • Scenario: Descripción del escenario. En este caso, el escenario sería un login básico de un usuario con credenciales válidas.
  • Given: Qué ha ocurrido antes.
  • When: Qué acciones se desencadenan. La cláusula “And” permite añadir otra acción dentro del “When”.
  • Then: El resultado deseado. Si no se cumple, el resultado de ejecutar el escenario sería de fallo.

A partir de este escenario de ejemplo podríamos ir añadiendo nuevos escenarios a “Login” como por ejemplo un login con credenciales no válidas o login de un usuario cuya cuenta está caducada. El paso siguiente sería generar la estructura del código necesario mediante la herramienta de SpecFlow y empezar a implementar los tests generados.

Frameworks recomendados para .Net:

Por último os dejo un par de recomendaciones de frameworks de BDD para .Net:

Si las especificaciones no sólo van a ser escritas y usadas por los desarrolladores, los dos frameworks más recomendados son SpecFlow y Nbehave, estando actualmente SpecFlow más extendido.

En caso contrario, se pueden usar otros frameworks como NSpec cuyo uso es más cercano al lenguaje de programación.

Para saber más sobre cómo Sogeti puede ayudarle en el desarrollo de aplicaciones para su negocio, visite: www.es.sogeti.com/Soluciones/Tecnologia-microsoft/Custom-Development/

Más información:

JavierSanzNietoJavier Sanz

.NET Architect | Soluciones Microsoft | SOGETI ESPAÑA

One thought

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s