Introducción: TDD vs BDD
El desarrollo dirigido por pruebas (TDD, del inglés Test Driven Development) es una metodología de desarrolo de software basado en dos prácticas:
- Escribir las pruebas primero (Test First Development)
- Refactorización
En primer lugar, se escribe una prueba que evidentemente fallará, pues el código aún no está implementado. A continuación, se implementa el código para que la prueba pase satisfactoriamente y seguidamente, se refactoriza nuestro código.
Por su parte, el desarrollo dirigido por comportamiento (BDD, del inglés Behaviour Driver Development) es una evolución de TDD. Al igual que en éste, escribiremos las pruebas antes de escribir el código pero en este caso, en vez de escribir pruebas unitarias, escribiermos pruebas que verifiquen el comportamiento del código y su correcto funcionamiento desde el punto de vista del equipo de negocio.
¿Qué es Cucumber?
Cucumber es una herramienta que permite la ejecución de descripciones funcionales en texto plano como test automáticos de aceptación, que se aprovecha de las ventajas del enfoque BDD para acercar la capa de negocio a la capa de tecnología de una empresa. Este proceso trata de combinar los aspectos puramente técnicos y los de negocio, de manera que tengamos un marco de trabajo y un marco de pruebas en el que los requisitos de negocio formen parte del proceso de desarrollo.
Aplicando este modelo de ejecución de pruebas integradas, buscamos que la definición de cada funcionalidad del sistema sea escrita de manera conjunta por el equipo de negocio y el equipo de desarrollo. De esta forma, pasaremos de tener una lista de requisitos priorizados que el “product owner” presenta al equipo de desarrollo, a una lista de pruebas de comportamiento que pasan como tareas al Sprint Backlog.
Partiremos de historias de usuario y describiremos lo que tiene que hacer esa nueva funcionalidad, haciendo uso de un lenguaje específico para BDD llamado Gherkin, que nos va a permitir describir todas nuestras funcionalidades de una misma forma.
Este lenguaje es lo que llaman en DDD (Domain Driven Design) un lenguaje obicuo, es decir, un lenguaje semiformal que es compartido por todos los miembros de un equipo de desarrollo de software, tanto desarrolladores como personal no técnico; facilitando así la comunicación entre todos los miembros implicados en el proyecto.
Una de las principales características que tiene Gherkin, es que para empezar a aplicar BDD a nuestro proyecto solo necesitaremos conocer 5 palabras a partir de las cuales vamos a construir las sentencias con las que vamos a describir las funcionalidades:
- Feature: Nombre de la funcionalidad que se va a probar, es decir, historia de usuario que queremos abarcar. A partir de aquí empezaremos a construir nuestros escenarios de prueba.
- Scenario: Describe cada caso de prueba que vamos a probar.
- Given: Provee contexto para el escenario en que se va a ejecutar el test. Incluye los pasos necesarios para poner al sistema en el estado que se desea probar.
- When: Especifica el conjunto de acciones que lanzan el test. La interacción del usuario que acciona la funcionalidad que deseamos testear.
- Then: Especifica el resultado esperado en el test. Observamos los cambios en el sistema y vemos si son los deseados.
Entre muchas de las ventajas que tiene el uso de esta herramienta, hay que destacar la facilidad de integración con los distintos IDEs de desarrollo con los que trabajamos. En el caso en el que nos atañe a nosotros, la ejecución de pruebas automatizadas con Eclipse es muy sencilla, tan sólo necesitamos incluir las dependencias en el pom.xml, y definir un controlador encargado de escanear las “features” y las distintas sentencias que hayamos implementando para la definición funcional de cada uno de los requisitos.
Una vez ejecutado los test cucumber, Eclipse nos mostrará el resultado de los mismo tal y como aparecen en la siguiente imagen:
En el ejemplo podemos ver cómo se hace un chequeo global, desde el nivel de sentencia hasta el nivel de “feature”. Del mismo modo, si alguna de las sentencias ha sido fallida, Eclipse nos lo indicará junto con un pequeño reporte de por qué ha sido ocasionado dicho error.
Como podemos ver sobre este ejemplo, el lenguaje utilizado es un lenguaje común y sencillo, que es entendible por cualquiera de las partes que conforman el proyecto, por lo que la comunicación y los acuerdos entre la parte de negocio y la parte de desarrollo irán siempre en paralelo y evitaremos los típicos errores de concepto/alcance en el DoD de la tareas.
Como conclusión, destacar la potencia que nos aporta este tipo de herramientas a la hora de la automatización de pruebas; ya no solo por la rapidez con la que podemos verificar modificaciones del código (pruebas de regresión); si no por la cantidad de información en forma de gráficas y estadísticas que nos aporta para mejorar la eficiencia de nuestro código, que al fin y al cabo, como desarrolladores que somos, es en lo que tenemos que basar nuestro trabajo.
Más articulos sobre automatización de pruebas, aquí.
