Un ejemplo de Cucumber para hacer BDD (Behavior driven development)

BDD tiende un puente para que los expertos del negocio y los informáticos se entiendan sin fisuras. BDD alienta la colaboración, construye compresión compartida sobre el comportamiento esperado del sistema, produce documentación que guía el desarrollo y permite validar el comportamiento del sistema de forma automática.

Trabajando en rápidos y pequeños ciclos mejora la retroalimentación y el flujo de valor. Hacer BDD es hacer tres cosas una y otra vez: se toma una pequeña funcionalidad y se conversa sobre los detalles de cómo se espera que el sistema se comporte usando ejemplos concretos, luego se documentan esos ejemplos en una forma en la cual se pueden automatizar y se corrobora que hay acuerdo, para terminar se codifica con lenguaje Guerkin el comportamiento descrito en cada ejemplo. A estas tres actividades se las llama: Descubrir, formular y automatizar.

La idea es hacer cada nueva funcionalidad en partes muy pequeñas (ejemplos) e iterar rápidamente. Cada vez que se implementa un ejemplo se añade algo valioso al sistema y se está en disposición de responder a posibles cambios como resultado de la retroalimentación recogida de los expertos en el negocio. Los ejemplos documentados guían el desarrollo y permiten al equipo tener confianza y progresar en la construcción del sistema. A la documentación que se va construyendo se le llama “documentación viva” porque el código representa la documentación y la documentación refleja el conocimiento compartido del equipo sobre lo que el código hace. Cucumber es una herramienta que sirve para hacer BDD y se va a usar a continuación para mostrar un ejemplo de lo explicado hasta aquí.

El ejemplo está basado en el curso online que suministran en Escuela Cucumber de forma gratuita, sólo hay que registrarse. El ejemplo tiene la siguiente estructura.

El contenido de Belly.feature es la codificación del ejemplo en Guerkin. La idea expresada es que si comes menos de 42 galletas y pasa más de una hora vas a estar hambriento y tu estómago va a gruñir, pero si has tomado más de 42 galletas no gruñirá.

La implementación del ejemplo para que la librería de Cucumber pueda ejecutar la prueba escrita en Guerkin en Belly.feature está en StepsBelly.java.

La funcionalidad del negocio está en Belly.java, esta aplicación determina si la barriga(belly) está llena o no después de haber transcurrido una hora y haber consumido una determinada cantidad de galletas.

Resumen

Estos tres ficheros son una pequeña muestra de lo que BDD, Guerkin y Cucumber pueden hacer para mejorar el desarrollo de software.

• Belly.Feature está escrito en un lenguaje entendible por el usuario y expresa lo que él espera que el sistema haga.
• StepsBelly.java es la implementación en java de Belly.Feature, cuando se ejecuta valida lo que se espera que haga la aplicación. Hay que tener en cuenta que lo que se espera que haga la aplicación lo ha escrito el experto en el negocio.
• Belly.java es la aplicación cuya funcionalidad se comprueba automáticamente con StepsBelly.java que se ejecuta con Cucumber.

No hay fisuras posibles entre lo que quiere el experto en el negocio y lo que codifica el desarrollador. Bueno hay que estudiar cómo usar todo esto en el mundo real, pero eso es otra historia…..

La economía del software según J. B. Rainsberger

Este artículo está basado en una conferencia de 2019 titulada “The economics of software design” de J.B. Rainsberger y que está disponible en Youtube en ver conferencia .

Lo que aquí relato es mi libre interpretación de lo que cuenta Rainsberger, lo digo porque puedo estar equivocada y tergiversar sus palabras. O sea son mis palabras, no las suyas, por si acaso. Es para que no me pase lo mismo que al tipo de la cola del cine en la película “Annie Hall” cuando habla sobre el trabajo de Marshall MacLujan ver escena.

El objetivo de la conferencia es explicar porque son necesarias prácticas ágiles a la hora de desarrollar software. Rainsberger con mucho talento sigue un hilo sólido que explica a desarrolladores y no desarrolladores porqué usar practicas ágiles va a mejorar los sistemas de información.

Rainsberger dice que hay tres asuntos importantes en los que hay que centrar la atención cuando se desarrolla software:

• Las funcionalidades desarrolladas (Features)
• El diseño del software (Design)
• La retroalimentación (Feedback)

Funcionalidades desarrolladas

La refactorización es la piedra angular del desarrollo de código. Esta refactorización facilita mejorar el coste marginal. El coste marginal es un término financiero que se puede definir como el incremento de coste al producir N+1 unidades de determinado producto, respecto al coste de producción de N unidades. Llevando esto al mundo software, se puede traducir en el coste de añadir una nueva funcionalidad o cambiar una funcionalidad ya existente. Es menor de añadir o modificar funcionalidades si el sistema está bien diseñada, es decir no es un galimatías. Los patrocinadores del software (financiero de la empresa u organismo) entienden de costes marginales, los desarrolladores de diseño del software. Entonces, si para tener un mejor coste marginal es necesario refactorizar los promotores entienden que refactorizar es necesario, los desarrolladores ya lo saben. La forma de refactorizar constantemente es utilizar TDD (Test Driven Development).

Diseño del software

Para su exposición Rainsberger utiliza el siguiente gráfico.

Aquí la curva representada por g representa el aumento del coste de seguir modificando un sistema que no se desarrolla con “Diseño Evolutivo”. Inicialmente desarrollar el sistema es menos costoso, pero con el tiempo el coste de mantenerlo se eleva exponencialmente, según Rainsberger siguiendo el comportamiento del interés compuesto según Bernoulli, de hay la formula (1+1/n)ⁿ -> e. Sin embargo la curva representada por f corresponde a los sistemas que se desarrollan con “Diseño Evolutivo” (básicamente empleando TDD), en estos el diseño está mejorando constantemente y eso contribuye a que aunque cada vez el sistema sea más complejo el crecimiento de costes sea mucho más moderado. En términos más vulgares que el galimatías sea menor, aunque la complejidad sea mayor.

También dice Rainsberger que el punto t₀ en el caso de los sistemas que no se desarrollan con "Diseño Evolutivo" es el momento en que económicamente es más rentable tirar el sistema y hacerlo de nuevo. Cómo según él nadie sabe calcular cuando llega ese momento, es mejor trabajar con “diseño evolutivo” para evitar el desastre.

Retroalimentación

En cuanto a la producción del software existe un modelo clásico llamado “En cascada” que implica las fases:

Requisitos -> Análisis-> Diseño-> Codificación -> Pruebas -> Puesta en marcha

En este modelo la retroalimentación se ejecuta demasiado tarde. Esto provoca que la cantidad de re-trabajo suela ser ingente porque cuando algo no se ajusta a lo esperado ya hay mucho que cambiar.

En “XP (eXtreme Programming de 1999)” se expuso que era mejor realizar un ciclo de desarrollo y pruebas constante que pusiera en evidencia si lo que se estaba desarrollando era lo que se necesitaba. XP y a continuación Agile aconsejan prácticas que mejoran la retroalimentación: pequeños ciclos de desarrollo, pruebas unitarias para conocer el estado interno del sistema y pruebas de aceptación para saber si el sistema está de acuerdo con las necesidades del usuario.

Rainsberger expone que las técnicas para llevar esto a cabo son TDD y BDD. También las prácticas de DevOps ayudan a la retroalimentación y facilitan la labor coordinada de los equipos de desarrollo y operaciones.

Conclusiones

Esta conferencia apoya de forma empírica y heurística el desarrollo basado en técnicas ágiles.

No hay fórmulas mágicas, pero desarrollar software no es fácil y yo también estoy convencida de que todas las prácticas ágiles contribuyen a que el mundo del desarrollo de software mejore.

Buenas noticias, eso nos beneficia a todos a los informáticos y a los no informáticos.