Una de BDD, Specification by Example y Cucumber
Sobre comportamientos, especificaciones y pepinos
Como seguramente algunos sepáis, en los Coding Stones además de trabajar en proyectos para clientes, desde hace un tiempo que empezamos a dar servicios de formación y mentoring.
Pues bien, hace un par de meses se pusieron en contacto con nosotros desde una multinacional, para ver si podíamos ayudarles a introducir en su departamento de desarrollo en España prácticas de BDD a través de Cucumber.
Tras hablarlo en el equipo y un par de llamadas más con el cliente para aclarar dudas, vimos que éramos capaces de diseñar una formación a partir de la que podían empezar a sacar partido desde el inicio.
Una de las cosas que más nos preocupó fue el no simplemente mostrar Cucumber como herramienta, enfocándonos meramente en la automatización. Si no en procurar que se entendiera bien BDD, ya que una de las malas prácticas más habituales en el uso de Cucumber es verlo solamente como una herramienta de testing.
Cuando se habla de BDD hay quienes defienden que es simplemente hacer TDD bien. Dan North, quien acuñó el término, defiende que no es sólo hacer TDD bien ya que BDD puede aplicarse de un modo más amplio.
Por este tipo de cosas nos parece que el concepto de BDD puede llevar a confusión. Entonces introdujimos el de Specification by Example, ya que resultaba más claro hablar de especificaciones ilustradas con ejemplos, y más combinado con una herramienta como Cucumber.
Muchos problemas cuando desarrollamos software surgen de los malentendidos de comunicación entre los diferentes miembros del equipo. Esto es lo que Specification by Example pretende resolver, conseguir un entendimiento compartido entre quienes trabajan en un proyecto y de este modo lograr: menos re-trabajo, mejor alineamiento de los diferentes roles del equipo, mayor calidad del producto y poder implementar cambios de forma más eficiente.
Así que decidimos proponer realizar un workshop de 2 días, con una primera parte en la que íbamos a trabajar más en la definición de requisitos de forma colaborativa y una segunda más centrada en las herramientas de automatización y en el uso de buenas prácticas.
En la primera sesión explicamos los conceptos de BDD, Specification by Example y algunos complementarios, como la importancia de tener y utilizar un lenguaje ubicuo. Luego nos centramos en practicar una sesión de Example Mapping a través de un par de casos prácticos. Posteriormente hicimos una pequeña introducción a Cucumber, para ayudar a ver la foto completa. Mientras que para finalizar estuvimos trabajando en la fase de refinamiento de los escenarios de ejemplo, donde ya acabamos escribiendo los escenarios en formato Gherkin.
En la segunda sesión volvimos a incidir en Cucumber, pero siempre procurando refrescar lo visto en la sesión inicial. Llevábamos preparados varios ejercicios con objetivos diferentes, unos enfocados en conocer más detalles de la herramienta y otros para tratar buenas prácticas tanto en la escritura de escenarios como en la implementación de los steps. También hablamos de la automatización de tests a nivel UI; a través de la combinación de Selenium con Cucumber; además del patrón Page Object para facilitar la mantenibilidad, legibilidad y robustez de este tipo de tests.
Al finalizar la segunda sesión facilitamos un pequeño ejercicio de retrospectiva, con el objetivo de que pusieran en común los beneficios de estas prácticas y que buscaran acciones concretas para empezar a utilizar BDD/Specification by Example en su día a día.
Estaremos pendientes de conocer cómo lo aplican y ver cómo van evolucionando en el medio plazo.
Si crees que podemos ayudarte en la implantación del uso o mejora de este tipo de técnicas y herramientas, péganos un toque y vemos si podemos tocar juntos.
