BDD (Parte 1) – Ruby + Cucumber

En el post anterior hablamos sobre cómo elegir un framework de automatización, y nombramos BDD.

En este post quiero exponer mi punto de vista sobre BDD, dado que he trabajado en un periodo de tiempo bastante largo con este framework, encontrando puntos a favor (los mas) y puntos en contra. Mucha gente critica el uso de BDD, diciendo que es una capa mas en el código que no aporta en nada, nos hace escribir los tests en texto plano y no re-utilizable y que nadie mas allá del QA va a ver ese código jamás. Desde mi punto de vista esa gente no llegó a trabajar correctamente con BDD, posiblemente lo único que hicimos fue implementar el framework en nuestro proyecto. Pero el potencial que tiene BDD va mas allá de la capa de mas que le agreguemos al proyecto, va en la forma de trabajo y en nuestro involucramiento en la organización.

Este será el primer post sobre BDD (haré mas de uno claramente) y haré foco en el proceso de trabajo a la hora de usar BDD, el cual debería de ser el ideal, y donde BDD muestra todas sus ventajas.

Primero.. que es BDD? BDD es un proceso de desarrollo de software, donde su sigla significa Behavior-driven development, también traducido al español como desarrollo guiado por comportamiento.

Y que significa esto? Primero que nada tenemos que entender que es un proceso de desarrollo en el cual necesitamos una organización que se involucre en que esto funcione, no sirve únicamente hacer tests con cucumber ya que no estaremos viendo los frutos de usar BDD.

 

En el diagrama anterior se muestra muy resumidamente como funciona este proceso de desarrollo, donde los QA escriben los tests que en un principio fallaran, luego implementaremos el código que los hará funcionar y por ultimo refactorizaremos el código.

La idea de BDD es que estemos involucrados desde el comienzo con las nuevas features, o “historias”, estando en la misma mesa que los analistas funcionales y los desarrolladores en el momento de la definición de las mismas. Mientras se va dando la reunión estaremos analizando y sacando apuntes de que es lo que deberemos probar.

Una vez analizado, escribiremos los casos de prueba en un lenguaje especifico para BDD, como Gherkin (el que usa Cucumber), el cual nos permitirá que sea comprendido tanto por personas como por pc’s. Este lenguaje nos permite poder mostrarle lo que probaremos a los analistas funcionales, desarrolladores y cualquier implicado, y que todos estemos hablando el mismo idioma y entendamos lo mismo.

Una vez escrito y discutido lo que probaremos, y cuando todos los implicados tengan claro que es lo que se probará (recordemos que la documentación que uno haga no sirve únicamente al QA, sirve al desarrollador también para que se tenga en cuenta nuestro análisis a la hora de desarrollar y evitar errores desde temprano), ejecutaremos esos tests y veremos que es lo que tenemos desarrollado en nuestros tests y que no. Esos “steps” o “pasos” que no tengamos y que fallarán, serán en los que trabajaremos.

Mientras desarrollo va creando la funcionalidad, nosotros vamos desarrollando los tests, de forma tal que cuando la funcionalidad esté lista para probar, nosotros ya tengamos nuestros tests prontos, y nuestra única tarea sea ejecutar dichos tests, reportando luego aquellos que fallaron y pasaron.

Como ven, nuestro trabajo va mas allá de desarrollar tests usando Cucumber, BDD es más que un framework en nuestro proyecto con tests en texto plano, es constante comunicación con el equipo, dinámica, trabajo en conjunto, y veremos también que es prolijidad, mantenimiento y sobre todo es documentación continua y actualizada sin tener que escribir documentación (raro no?).

En el siguiente post mostrare ejemplos de la estructura del proyecto de automatización, y un ejemplo de un test hecho con Cucumber y Ruby.

2 comentarios sobre “BDD (Parte 1) – Ruby + Cucumber

Agrega el tuyo

  1. Excelente Maxi! me interesa leer más de lo que tenés para compartir sobre BDD.

    Algo que he visto en lo que he trabajado últimamente con esto, que lo comenté acá https://www.federico-toledo.com/que-es-bdd/ y acá https://www.federico-toledo.com/ghost-inspector-mas-fondo/ es que le veo la gran ventaja de que uno se ve “obligado” a comenzar con la documentación de la prueba, y no va directo a automatizar algo. En el segundo link que puse, esto lo sufrí (y lo sigo viendo) por estar ajustando tests hechos por alguien más (que se fué de la empresa para la cual lo estoy haciendo) y no documentó nada de lo hecho. Si estuviese hecho con este enfoque, cada feature en Gherkin contaría cuál es el propósito de cada prueba.

    Abrazo

    Me gusta

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 )

Google photo

Estás comentando usando tu cuenta de Google. 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 )

Conectando a %s

WordPress.com.

Subir ↑

A %d blogueros les gusta esto: