PDF de programación - Desarrollo de una aplicación web utilizando Desarrollo Guiado por Comportamiento e Integración Continua

Desarrollo de una aplicación web utilizando Desarrollo
Guiado por Comportamiento e Integración Continua

Matías Mascazzini,  Mgter. Gladys Noemí Dapozo

Facultad de Ciencias Exactas y Naturales y Agrimensura. Universidad Nacional del Nor­

Licenciatura en Sistemas de Información

Av. Libertad 5470. Corrientes. Argentina.

[email protected]
 

 ,[email protected] 

deste.

Resumen. En los últimos años se avanzó en los conceptos de desarrollo de so­
ftware dirigido por comportamiento con el objetivo de superar las ineficiencias
y dificultades del desarrollo de aplicaciones. Se busca mejorar la comunica­
ción con el cliente para entregar valor para su negocio, haciendo la cosa co­
rrecta de forma precisa, adaptándose a los cambios que puedan surgir en el
proceso y definiendo cuándo se da por finalizado el software en función de las
pruebas de aceptación de cada historia de usuario. El objetivo de este trabajo
es profundizar estos conceptos y aplicarlos en un problema concreto, para eva­
luar sus ventajas e inconvenientes. Siguiendo una metodología de 4 etapas se
aplicaron  satisfactoriamente   estos   conceptos,  utilizando   además  Integración
Continua. Aplicando un proceso de software iterativo e incremental se desarro­
lló una aplicación web, destinada a gestionar premios con votaciones en línea;
apoyándose para alcanzar sus objetivos con una serie de herramientas. Se pudo
apreciar una mejora en el proceso de desarrollo al contar con una “documenta­
ción viva” que refleja fielmente y de forma actualizada lo que hace la aplica­
ción; y una retroalimentación, casi inmediata, surgida de las pruebas automati­
zadas generando un código más fácil de modificar.

Keywords: Desarrollos  Ágiles, Desarrollado  Dirigido  por Comportamiento,
Historias de usuario, Desarrollo Dirigido por Pruebas, Pruebas Unitarias, Prue­
bas de Aceptación, Automatización de pruebas, Integración Continua.

1   Introducción

Hace tiempo, se empezó a pensar en cómo superar las dificultades e ineficiencias
en el desarrollo de software. La dificultad radica en cómo hacer la cosa correcta para
los usuarios, que agregue valor a su negocio, y hacerla correctamente, dentro de los
plazos y presupuestos previstos; aceptando el cambio natural en los requerimientos y

EST 2015, 18º Concurso de Trabajos Estudiantiles. 44 JAIIO - EST 2015 - ISSN: 2451-76172respondiendo positivamente ante estos cambios. Y además determinar cuándo está
terminado el software.

En este marco, surge el agilismo para reducir los problemas clásicos del desarrollo
de programas, a la par de dar más valor a las personas que componen el equipo de
desarrollo.

Entre estos métodos ágiles, existen algunas prácticas en la que las pruebas pasan a
ser una herramienta de diseño del código y, por tanto, se escriben antes que el mis­
mo. De entre estas se destaca TDD (Test­Driven Development), utilizando pruebas
unitarias fue la precursora y BDD (Behavour­Driven Development) que propone po­
ner el foco en generar valor para el usuario final utilizando las pruebas de aceptación
y redefiniendo el dialogo con los usuarios en la búsqueda de un lenguaje ubicuo (co­
mún a todos) para lograr desde el primer momento hacer “la cosa correcta”, es decir
un software que agregue valor al usuario final. Con el soporte de las pruebas, las sub­
prácticas asociadas y las herramientas, éstas prácticas también logran “hacer la cosa
correctamente”.

1.1. BDD

Behavour­Driven Development (BDD), en español “Desarrollo Dirigido por Com­
portamiento”, es una práctica de diseño de software que obtiene el producto a partir
de expresar las especificaciones en términos de comportamiento, de modo tal de lo­
grar un grado mayor de abstracción. BDD pone un énfasis especial en cuidar los
nombres que se utilizan, tanto en las especificaciones como en el código. De esta ma­
nera, hablando el lenguaje del cliente, se mantiene alta la abstracción, sin caer en de­
talles de implementación.

Surgió en respuesta a las críticas que se encontraron en TDD; Dan North empezó a
hablar de BDD en un artículo llamado “Behavior Modification” en Marzo de 2006
[1]. Según North, BDD está pensado para hacer estas prácticas ágiles más accesibles
y efectivas a los equipos de trabajo que quieren empezar con ellas, de allí que su es­
quema sea muy similar al de TDD como se aprecia en la Figura 1, agregando una
capa de pruebas de comportamiento por encima de las pruebas unitarias. Principal­
mente propone que en lugar de pensar en términos de pruebas, se debería pensar en
términos de especificaciones o comportamiento. De ese modo, se las puede validar
más fácilmente con clientes y especialistas de negocio.  Poner el foco en el comporta­
miento logra un grado mayor de abstracción, al escribir las pruebas desde el punto de
vista del consumidor y no del productor.

Lo importante es que BDD puso el énfasis en que no eran pruebas de pequeñas
porciones de código lo que se creaba, sino especificaciones de requerimientos ejecu­
tables [2]. Un test de cliente o de aceptación con estas prácticas, a nivel de código, es
un enlace entre el ejemplo y el código fuente que lo implementa [3].

EST 2015, 18º Concurso de Trabajos Estudiantiles. 44 JAIIO - EST 2015 - ISSN: 2451-76173Se trata de actividades que comienzan desde las necesidades del usuario, para ir

deduciendo comportamientos y generando especificaciones ejecutables.

Fig. 1. Esquema BDD. (Fuente: elabora­
ción propia)

Fontela [4] comenta que la crítica  principal  de este enfoque de BDD y al de
ATDD (Acceptance Test­Driven Development) viene de que si bien se pueden deri­
var pruebas individuales de los contratos, es imposible el camino inverso, ya que mi­
les de pruebas individuales no pueden reemplazar la abstracción de una especifica­
ción contractual. La respuesta a esta crítica fue que, si bien las especificaciones abs­
tractas son más generales que las pruebas concretas, estas últimas, precisamente por
ser concretas, son más fáciles de comprender y acordar con los analistas de negocio y
otros interesados. Y que los ejemplos concretos son fáciles de leer, fáciles de enten­
der y fáciles de validar.

Fontela [4], agrega que al inicio esta técnica se enfocaba en ayudar a los desarro­
lladores a practicar “un buen TDD” pero el uso de BDD, más las ideas de ATDD,
han llevado a una nueva generación de BDD, como práctica y por las herramientas
que utiliza. El foco está ahora puesto en una audiencia mayor, que excede a los desa­
rrolladores, e incluye a analistas de negocio, testers, clientes y otros interesados.
1.1.2 Las historias de usuario en BDD

Buscando generar un lenguaje único entre el equipo de desarrollo y el cliente;
North propone simplemente estructurar la forma de describir las historias de usuario
con el formato Connextra: “Como <rol> deseo <funcionalidad> para lograr <benefi­
cio>”, o alguna variante compatible; más el agregado de las cláusulas Given­When­
Then (Dado, Cuando, Entonces) para ayudar a estructurar la explicación de una fun­
cionalidad, en la definición de los escenarios y hacer posible la ejecución de los crite­
rios de aceptación. Este formato captura: el interesado o su rol, el objetivo del intere­
sado para la historia y la tarea a realizar [5]. De esta manera una historia de usuario al
inicio tendrá una estructura como la siguiente:

EST 2015, 18º Concurso de Trabajos Estudiantiles. 44 JAIIO - EST 2015 - ISSN: 2451-76174Característica: [Nombre de la historia]
 

Como un [rol en la aplicación]

Para lograr [para alcanzar algún objetivo concreto]

Deseo [hacer alguna tarea o funcionalidad]

Luego la historia de usuario queda completa con los escenarios y sus ejemplos,
que representan los test de aceptación del cliente y determinan cuando una funciona­
lidad está completa. También se pueden usar “datos tabulados”, en los cuales se utili­
zan ciertas estructuras de tablas para expresar requerimientos y reglas de negocio, ya
que las reglas de negocio cambian menos que las interfaces gráficas. Estas tablas po­
sibilitan describir datos de entrada y de salida [6].

La visión de North era tener una herramienta que pueda ser usada por analistas de
sistemas y testers para capturar los requerimientos de las historias en un editor de
textos y desde ahí generar el esqueleto para las clases y sus comportamientos, todo
esto sin salir de su lenguaje del negocio [1].
1.1.3 Utilizando ejemplos como requerimientos

La mayor diferencia entre las metodologías clásicas y la Programación Extrema
(XP) es la forma en que se expresan los requerimientos de negocio. En XP [7] en lu­
gar de documentos, se consideran las historias de usuario con sus test de aceptación
[3]. 

Los tests de aceptación o de cliente, de las historias de usuario, son las condicio­
nes escritas de que el software cumple los requerimientos de negocio que el cliente
demanda.

El trabajo del analista de negocio se transforma para reemplazar páginas de reque­
rimientos escritos en lenguaje natural, por ejemplos ejecutables surgidos del consen­
so entre los distintos miembros del equipo, incluido por supuesto el cliente. 

En BDD la lista de ejemplos de cada historia, se escribe en una reunión (taller de
especificación) que incluye a responsables del producto, desarrolladores, responsa­
bles de calidad y otros interesados. Todo el equipo debe entender qué es lo que hay
que hacer y por qué, para concretar el modo en que se certifica que el software lo
hace. Como no hay una única manera de decidir los criterios de aceptación, los dis­
tintos roles del equipo se apoyan entre sí para darles forma.

1.2 prácticas asociadas a BDD

1.2.1 Integración Continua

La integración continua (del inglés “Continuous Integration” o simplemente CI),
es una práctica introducida en XP y luego muy difundida a partir del trabajo de Fow­

EST 2015, 18º Concurso de Trabajos Estudiantiles. 44 JAIIO - EST 2015 - ISSN: 2451-76175ler [8]. Consiste en automatizar y realizar, con una frecuencia al menos diaria, las ta ­
reas de compilación des