BDD a velocidad IA

BDD

Ya hemos hablado en post anteriores que cuando hablamos de BDD nos viene a la mente una “forma de automatizar tests”, pero en realidad Behaviour Driven Development va mucho más allá. Esta práctica de ingeniería comprende técnicas y herramientas que aplicamos desde el momento en que levantamos los requerimientos de nuestro producto (no de nuestro test sino de nuestro producto). Puedes consultar esos post aquí:

• BDD no es solo Gherkin — es conversación entre negocio y técnica (Los 3 amigos) para descubrir requerimientos, evaluar factibilidad, definir criterios de aceptación y hasta detalles de implementación y cómo vamos a probar.
• Gherkin y su implementación: feature files, steps, step definitions.

BDD fomenta (y a su vez, requiere) la máxima colaboración entre todos los involucrados en el proceso/ciclo de desarrollo de un producto/servicio, no va solo de testing y testers.

En este post vamos a ver una introducción rápida de BDD con links a más recursos y vamos a explorar cómo la IA nos puede ayudar en la implementación de cada una de las prácticas de BDD.

Los 3 amigos y Example Mapping

Es una práctica de BDD para descubrir requerimientos en la que participan:

• Product Owner o equipo de producto.
• Desarrollador.
• Tester.

Se usa el Example Mapping para dirigir estas conversaciones. Aquí puedes leer más sobre Example Mapping. Partimos de ejemplos y generamos reglas de negocio.

De Ejemplos a Gherkin

Cuando tenemos nuestros ejemplos, diseñamos nuestro escenario de test. Cada escenario tiene pasos que expresamos en lenguaje Gherkin: Given, When, Then, And, and But.

Gherkin es un lenguaje no técnico que puede ser leído por cualquier persona (como lenguaje natural) y que nos permite expresar comportamientos.

Los pasos más importantes son:

• Given: son las precondiciones para un escenario y preparación del ambiente para ejecutar nuestro test.
• When: la acción a realizar por el usuario (la acción que vamos a testear).
• Then: el resultado esperado. ¿Cuál es la respuesta que esperamos de parte del sistema?

De Gherkin al Código

Cuando tenemos nuestros tests escritos en Gherkin, podemos convertirlos en especificaciones ejecutables (código fuente). De esta forma podemos automatizar nuestros criterios de aceptación.

Para lograr estas especificaciones ejecutables, usamos:

• Feature file
• Page Object Model
• Step definitions

Aquí puedes profundizar acerca de Gherkin en código fuente siguiendo el mismo caso de estudio de este artículo.

Oportunidades de aplicar IA en BDD

Partiendo de que hay de todo en BDD: descubrimiento de requisitos y formulación de criterios de aceptación, y a partir de allí, la creación de pruebas automatizadas, ¿en qué fase, sesión o práctica podríamos aplicar Inteligencia Artificial?

Entre otras cosas, podemos:

• Pedirle a la IA que actúe como cada uno de los 3 amigos (con los roles de dueño de producto, desarrollador y tester).
• Traducir reglas de negocio con sus ejemplos en escenarios de prueba escritos en lenguaje Gherkin.
• Validar Gherkin.
• Escribir las pruebas automatizadas (implementando los steps y step definitions).

Vale la pena destacar que no significa que la IA sustituye el criterio de los 3 amigos sino que se convierte en el cuarto amigo, ayudándonos a descubrir requerimientos y a escribir y validar nuestras pruebas.

Setup

Y ahora sí, manos a la obra. Para desarrollar este ejercicio vamos a usar Claude Code, aunque puedes trasladar estos mismos conceptos, acciones y recursos a cualquier otra herramienta.

Pre-requisitos

• VS Code.
• Claude code. Ver instrucciones de instalación aquí.
• NodeJS.

Instalación Paso a Paso

1. Crear una carpeta en la que vamos a trabajar. Ejemplo: practica-claude-discovery
2. correr comando claude
3. correr comando instalar webdriverIO
4. Salir de claude con el comando exit
5. Verificar instalación y run de tests corriendo el comando npm run wdio (creado en el achivo package.json).
6. Crear skill discover. Para crear una skills, creamos una subcarpeta dentro de la carpeta .claude. Este skill no lo escribí yo, lo tomé del repositorio cashback-rewards de John Ferguson Smart, referente de BDD, autor de los libros BDD in Action, primera y segunda edición. Es tan simple como descargar esta carpeta y pegar todo el contenido dentro de la carpeta .claude.

Instalación Rápida

También puedes descargar este repositorio creado para este ejercicio (la rama inicial de trabajo es “inicio”) y solo tienes que correr npm install.

Discovery de Requerimientos con IA

Para ese ejemplo usaremos la web: https://practice.expandtesting.com/webpark

WebPark es una calculadora de costos de estacionamiento de aeropuerto. Tiene formulario con fecha/hora de entrada y salida, selector de tipo de estacionamiento, y un botón que calcula el costo.

Los 5 tipos de estacionamiento y sus reglas de negocio

De aquí en adelante, mira este video explicativo de cómo usar la Inteligencia Artificial para ayudarnos en el proceso de descubrir requerimientos generando ejemplos, contra-ejemplos, preguntas y reglas que luego vamos a convertir en pruebas Gherkin y en código fuente:

El prompt utilizado es (texto tomado de Webpark):

/descubrir Imagine we were to design a parking cost calculator that calculates the price of parking tickets at the airport. There could be different parking sites like

Valet Parking
Short-Term Parking
Long-Term Garage Parking
Long-Term Surface Parking
Economy Lot Parking
With each site having its own set of rules how a ticket price is calculated:

Valet Parking
18.00€ per day
12.00€ for five hours or less
Short-Term Parking
2.00€ first hour; 1.00€ each additional 1/2 hour
24.00€ daily maximum

Long-Term Garage Parking
2.00€ per hour
2.00€ daily maximum
72.00€ per week (7th day free)

Long-Term Surface Parking
2.00€ per hour
10.00€ daily maximum
60.00€ per week (7th day free)

Economy Lot Parking
2.00€ per hour
9.00€ daily maximum
54.00€ per week (7th day free)

De Gherkin al Código

Después de tener diseñados nuestros escenarios de prueba, nuestro objetivo es transformar esas reglas de negocio y especificaciones de Gherkin en código ejecutable mediante el uso de herramientas como Claude Code y WebdriverIO.

Yo estoy usando Claude Code pero como vamos a usar Skills, estas son transferibles a cualquier herramienta de IA que decidas usar.

Skills para BDD

A nuestro setup, anteriormente descrito, agregamos 3 Skills specializadas en BDD:

• Cucumber Fundamentals:
• Cucumber Step Definitions:
• Cucumber Best Practices.

Si descargaste este repositorio ya están las skills en la rama “inicio”.

Las skills fueron tomadas de The Bushido Collective listado en Skills.sh.

Escribiendo los feature files a partir de los ejemplos y reglas

Teniendo ya las reglas definidas en el archivo calculadora-tarifas-parking-aeropuerto.md nuestro siguiente paso es crear los feature files usando el skill cucumber-step-definition y usamos este prompt:

/cucumber-step-definitions escribe los feature files de las pruebas contenidas en el archivo doc/specs/calculadora-tarifas-parking-aeropuerto.md en la carpeta test/features. Escribe un feature file por cada regla. Escribe cada feature file tomando como referencia la estructura del archivo test/features/login.feature. Escribe todo en ingles

Especifico en qué carpeta quiero que guarde cada feature. Y además que escriba todo en inglés, ya que es un estándar que todo el código lo escribimos siempre en inglés. Sí se puede escribir Gherkin en español y la implementación la puedes consultar en **Cómo pasar nuestros test Gherkin a español u otro idioma?**

Un ejemplo de los feature files generados es:

Luego Claude sugiere now write the step definitions for these features files y lo cambio por el siguiente prompt:

now write the step definitions for these features files in the folder test/step-definitions. write the page object under the folder test/pageobjects taking into account that the tests will be user interface tests in the website <https://practice.expandtesting.com/webpark> where a form with id=reservationDetailsForm is found. Inputs of the form are Parking Lot, Entry date, entry time, exit date, exit time… so you might need to manage the duration giving dates and times

De nuevo especifico en qué carpeta quiero que se guardo cada archivo de pageobjects y de step-definitions.

También le digo que los tests son de interface de usuario y especifico cuál es la URL donde ya existe esa interfaz de usuario, y ésto es super importante, porque sino, Claude va a desarrollar todo un API para luego escribir las pruebas. También proveo detalles del formulario que va a encontrar en la interfaz de usuario, lo suficiente para que nuestras pruebas sean exitosas.

Entonces veamos el Page Object creado parking.page.js:

Y un ejemplo del Step Definition file parking.step.js:

Conclusiones

• Podemos usar Claude Desde la creación de las especificaciones hasta la creación del código de nuestras pruebas automatizadas.
• Hay skills preconfiguradas que podemos usar para casi cualquier cosa que deseemos hacer, entre ellas, escribir pruebas de software BDD. No hace falta empezar desde cero cuando podemos ayudarnos de estos recursos existentes.
• Es mejor ir paso a paso en lugar de pedirle a la IA que cree pruebas a partir de los ejemplos. Los pasos serían: 1) generar los ejemplos, 2) validar ejemplos, 3) crear las reglas, 4) revisar entre todos (desarrollador, tester y producto), 5) generar los feature files a partir de las reglas y ejemplos, 6) escribir page objects y step definitions. De esta manera podemos ir revisando, validando, iterando y refinando en casa paso, en lugar de intentar revisar todo al final. También ayuda a evitar alucinaciones y podemos volver a un paso anterior sin dañarlo todo y tener que empezar desde cero.
• El código generado por estas skills sigue todas las buenas prácticas tanto de javascript como de webdriverIO y de Cucumber.
• La IA, ya sea Claude o cualquier otra puede actuar como un “cuarto amigo” en el proceso BDD, desde el discovery de requerimientos hasta ayudando a automatizar criterios de aceptación de manera eficiente y siguiendo buenas prácticas de ingeniería.