BDD y TDD en el mundo real (II) – Ciclo desde la fuente

En el artículo anterior de esta serie examinamos en profundidad TDD, y observamos el proceso de ir de un requerimiento al código, definiendo primero las pruebas y luego implementando y refinando la solución.

Tal como comentamos TDD nos ayuda a construir una clase o un módulo. Pero en la vida real, necesitaremos construir escenarios completos.

Esto es justamente lo que proporciona BDD y veremos que este se puede integrar con TDD para generar un ciclo completo de desarrollo basado en calidad “desde la fuente”.

BDD

El Desarrollo Guiado por el Comportamiento o BDD (Behavior Driven Development) es un proceso que amplía las ideas de TDD y las combina con otras ideas de diseño de software y análisis de negocio para proporcionar un proceso (y una serie de herramientas) a los desarrolladores, con la intención de mejorar el desarrollo del software.

En BDD no probamos solo unidades o clases, probamos escenarios y el comportamiento de las clases a la hora de cumplir dichos escenarios, los cuales pueden estar compuestos de varias clases.

BDD toma este primer enfoque de prueba presentado por TDD y, añade semántica funcional y de usuario; e intenta seguir la misma fórmula para todo el software.

BDD ayuda a definir esos flujos, pero no nos ayuda a diseñar el software, como lo hace TDD. Sin mencionar si estamos limitados con los sistemas existentes. Por tanto, ambas metodologías son complementarias.

BDD ha evolucionado a partir de prácticas ágiles establecidas y está diseñado para hacerlas más accesibles y efectivas para los equipos en la entrega de software ágil. Con el tiempo, BDD ha crecido para abarcar un espectro más amplio del análisis ágil y de las pruebas de aceptación automatizadas.

Definición de pruebas en BDD

Los DSL (Domain-Specific Language) son lenguajes naturales que expresan comportamiento y definen la salida esperada.

Los más usados a la hora de definir escenarios en BDD, suelen constar de pasos, que tienen el siguiente formato o plantilla “given-when-then”:

• Dado: los pasos necesarios para poner al sistema en el estado que se desea probar
• Cuando: La interacción del usuario que acciona la funcionalidad que deseamos testear.
• Entonces: En este paso vamos a observar los cambios en el sistema y ver si son los deseados.

Los Test de Aceptación son aquellos destinados a determinar si los requisitos de cierta funcionalidad han sido cumplidos.

Los usuarios finales, no tienen por qué preocuparse por los detalles de la implementación, si no centrarse más en qué la parte funcional cumple las expectativas creadas al inicio del Sprint.

Estas pruebas de aceptación se derivan directamente de los Criterios de Aceptación de una historia de usuario.

Los DSL sirven para definir dichos test de aceptación de una manera programática y por tanto automatizable.

DSL, Gherkin y BDD

Gherkin es el lenguaje específico de dominio (DSL) utilizado por los practicantes de BDD de todo el mundo como su gramática legible para los negocios. Gherkin tiene su propia forma de organizar las historias de usuario ágiles usando reglas de formato como características, escenarios, pasos, ejemplos, etc.

Una vez tengamos las historias de usuario, generaremos un archivo con los test de características, usando lenguaje Gherkin. Estos después los implementaremos usando frameworks específicos.

Existen diferentes frameworks y librería en distintas tecnologías para especificar las pruebas BDD, como JBehave para Java, Cucumber para JS o behave para Python. Todos soportan el estándar Gherkin.

De la historia de usuario a la definición del test BDD

Las historias de usuario tienen el siguiente formato:

• Como [rol/usuario]
• Quiero [funcionalidad/característica]
• Para [Beneficio/valor]

La fortaleza de las historia de usuario es que obligan a identificar el valor de entregar una historia cuando se definen por primera vez. Cuando no hay un verdadero valor comercial para una historia, a menudo se reduce a algo así como:

 “. . . Quiero [alguna característica] para que [simplemente lo haga, ¿de acuerdo?] “.

Esto puede hacer que resulte más fácil descifrar algunos de los requisitos más esotéricos.

A partir de este punto de partida, tal como dedujeron Dan North y Chris Matts (y todos los probadores ágiles conocen): el Comportamiento de una historia es simplemente su Criterio de Aceptación.

Si el sistema cumple todos los criterios de aceptación, se comporta correctamente; si no lo hace, no lo es.

Mediante los DSL se describen los criterios de aceptación en términos de escenarios, que tomaron la siguiente forma:

• Dado un contexto inicial,
• Cuando un evento ocurre
• Entonces asegurar la salida

Caso práctico: Una aplicación para gestión Agile

Tomaré el ejemplo de un de los productos TargetProcess.

La historia de usuario:

• Como un Scrum Master
• Quiero ver el progreso del tiempo de Lead / Cycle
• Para que yo sepa si estamos mejorando nuestro proceso de desarrollo o no.

Entonces, ¿cómo sabemos cuándo hemos entregado esta historia? Hay varios escenarios a considerar:

Escenario #1

• Dado que la sección de Informes en proyecto y la práctica de Tracking  de errores está deshabilitada
• Cuando navegue al Informe de “Lead and Cycle Time”
• Entonces veré el gráfico de Lead Time

Y el cuadro contiene 1 línea para las historias

Escenario # 2

• Dado que la sección de Informes en proyecto y la práctica de Tracking  de errores está deshabilitada
• Cuando navegue al Informe de “Lead and Cycle Time”
• Entonces veré el gráfico de Cycle Time

Y el cuadro contiene 1 línea para las historias

Escenario # 3

• Dado que la sección de Informes en proyecto y la práctica de Tracking  de errores está habilitada
• Cuando navegue al Informe de “Lead and Cycle Time”
• Entonces veré el gráfico de Lead Time

Y la tabla contiene 2 líneas (para historias y errores)

Escenario # 4

• Dado que la sección de Informes en proyecto y la práctica de Tracking  de errores está habilitada
• Cuando navegue al Informe de “Lead and Cycle Time”
• Entonces veré el gráfico de Cycle Time

Y la tabla contiene 2 líneas (para historias y errores)

Buenas prácticas en BDD

• La pirámide de pruebas: BDD admite la automatización de pruebas de componentes y de la interface de usuario (UI). Y como buena práctica general para el mantenimiento y la mejora futura, se recomienda que se siga el enfoque de la pirámide de pruebas en términos de número de pruebas y cobertura en todo el espectro de pruebas automatizadas. (Pruebas unitarias, Prueba de componente (API) y Pruebas de UI).
• Background de las pruebas: El background de pruebas debe limitarse solo a cualquier actividad de requisitos previos que no tenga ninguna acción o datos específicos de una prueba individual. Estas actividades serían, por ejemplo, iniciar sesión, limpiar o configurar los datos básicos (no específicos de las pruebas individuales).
  • Beneficios: Es probable que la configuración de datos específicos de la prueba cambie para caso de prueba individuales, lo que resulta en complejas declaraciones de funciones de fondo.
• Objetivos de las pruebas: Establecer los objetivos de una prueba es clave. En principio, cada escenario en una característica debe cubrir un solo objetivo. Sin embargo, esto no necesita ser una regla estricta, si sería más adecuado para escenarios específicos cubrir objetivos múltiples. (Validación y resultados, por ejemplo).Como guía, las pruebas de UI solo deberían cubrir trayectos válidos extremo a extremo. (Se pueden incluir mensajes de advertencia según corresponda).Los objetivos de la prueba no deben confundirse con las condiciones de la prueba. Cada objetivo puede tener múltiples condiciones de prueba (puntos de verificación).
  • Beneficios: Separación de responsabilidades y mantenimiento más fácil.
• bdd-y-tdd-en-el-mundo-real-iipide que TA / BA escriban las mismas acciones en diferentes formatos. Dado que el archivo de características de BDD está escrito en un idioma plano, normalmente inglés (por ejemplo, Gherkin [https://martinfowler.com/bliki/BusinessReadableDSL.html]), las mismas acciones podrían escribirse de diferentes maneras.
• Escenarios guiados por datos: Es necesario asegurarse que los escenarios se basen en datos (tanto como sea posible).
  • Beneficios: Evita la duplicación de escenarios y permite una mayor flexibilidad para el mantenimiento.
• Scripts independientes: Los scripts deben ser independientes de otros scripts, para que estos puedan ejecutarse por sí mismos.
  • Beneficios: A medida que el paquete de prueba sigue creciendo, es importante poder investigar los fallos individuales y poder mejorar para futuros cambios. Si se crea una interdependencia compleja, será más difícil y podría terminar siendo inmanejable para los equipos de proyectos más nuevos.
• Idempotente: El paquete de prueba o la secuencia de comandos individual debe volver a ejecutarse en un entorno de destino y dar como resultado exactamente el mismo comportamiento que la primera ejecución. Un script debe estar diseñado para limpiar sus actualizaciones o garantizar la existencia del estado de datos requerido como parte de los antecedentes para llevar a cabo la prueba.
  • Beneficios: Garantiza que el usuario que no esté familiarizado con una funcionalidad en particular pueda ejecutar y analizar los resultados.
• Lenguaje de negocio/comercial: El archivo de características debe estar escrito en lenguaje comercial sin referencia a objetos técnicos.
  • Beneficios: El objetivo final de BDD es tener especificaciones de negocio comprensibles que se utilicen para validar el sistema creado. Cuando estas especificaciones se vuelven técnicas, se frustra el propósito del paquete de prueba.

Reflexiones finales

BDD nos permite definir construir escenarios completos y complejos; y probarlos. Nos permite verificar el aspecto funcional de una aplicación o servicio en todo su flujo, extrayendo el valor a validar desde las propias historias de usuario, con sus criterios de aceptación y extrapolándolos a comportamientos esperados de la aplicación.

Usando DSL con estándar Gherkin, podemos definir dichos comportamientos de manera estándar y para su implementación tenemos distintos frameworks para las diferentes tecnologías que necesitemos.

Tal como comentamos, BDD ayuda a definir flujos y escenarios, pero no nos ayuda a diseñar el software, como lo hace TDD. Sin mencionar si estamos limitados con los sistemas existentes. Por tanto, ambas metodologías son complementarias. En el próximo post veremos cómo integrar BDD con TDD en un proceso Agile.