Skip navigation

Contenido

 

            

Introducción

Este artículo intenta acercar al lector a la práctica de desarrollo orientado a la calidad utilizando la técnica de BDD, a partir de la descripción conceptual de su utilización, beneficios, casos de uso y un ejemplo.

Objetivos

Brindar la información y los beneficios sobre esta técnica para que el lector tenga la facultad de evaluar y decidir si dicha práctica es conveniente para el proyecto en el que está trabajando.  

Behavior Driven Development

Behavior Driven Development (también conocido como BDD) es una técnica de desarrollo ágil que fomenta la colaboración entre los desarrolladores, las personas encargadas de asegurar la calidad (testers) y los analistas en un proyecto de construcción de software. El concepto es una evolución de Test Driven Development (también denominado TDD) y Extreme Programming (XP), cuyo objetivo es  tener un mejor control de la calidad del software que está siendo producido.

La idea principal de BDD es enfocar el esfuerzo en describir cómo se debería comportar la aplicación (o parte de ella), plasmar esto en un sistema de análisis automático con la ayuda de herramientas y luego desarrollar, a partir de la necesidad de cumplir con el comportamiento esperado. Si el análisis ha sido lo suficientemente especifico, el desarrollo estará completo y funcionando tal como se espera cuando las métricas de las herramientas utilizadas demuestren que todos los escenarios de evaluación de comportamiento han sido finalizados con éxito.

Es sabido que hacer un análisis exacto es muy difícil (si no imposible) por lo cual es necesario que exista una buena comunicación entre el analista, el tester y el desarrollador para así lograr tener una corrección continua, especialmente cuando el cliente no sabe bien lo que precisa, como sucede en la mayoría de los casos.

A continuación se describen los tres roles principales mencionados anteriormente. Puede suceder que éstos estén fundidos en 1, 3 o X (equis) cantidad de personas, pero no necesariamente:

  • Analistas
    • encargados de reelevar el comportamiento de la aplicación que satisface al cliente.
  • Testers
    • son quienes llevan el relevamiento del analista a un conjunto de reglas que aplicadas al software en cuestión generan métricas para indicar el estado de avance del proyecto.
  • Desarrolladores
    • encargados de implementar las funcionalidades del sistemas necesarios para cumplir con el comportamiento esperado.

Caso de uso

Para lograr una explicación mas pragmática, a modo de ejemplo se utilizará el caso modelo elegido al azar el cual consiste en un modulo de validaciones de servicios.

Introducción

El ejemplo se trata de módulo de validación de invocaciones a servicios, el cual necesita la información de un usuario y la lista de contratos a los cuales el usuario quiere activar un servicio. A partir de estos datos, el módulo debe utilizar reglas definidas por el cliente para decidir si el servicio puede ser invocado o no.

El Analista: Relevando el comportamiento

Desde la postura del analista, luego de una reunión con el cliente, se desprende el siguiente requerimiento:

  • Cuando se activa un servicio para un contrato (línea de teléfono) por el sistema es necesario que la forma de pago sea POSPAGO

Sabiendo esto, se puede detallar el siguiente comportamiento de la aplicación en tres pasos:

Dado Un contrato pospago
Cuando Intento activar el servicio
Entonces La validación termina sin errores

De esta manera se está describiendo un escenario de comportamiento, el cual está compuesto por tres partes importantes que es preciso saber identificar:

  • Precondición: Estado del sistema necesario y suficiente producto de la abstracción del problema, en este caso es preciso un contrato pospago. Se dice que es necesario porque sin esto el sistema no puede funcionar y suficiente porque dada la abstracción, solamente con esta información el modulo debería poder resolver el problema.
  • Acción: Es la funcionalidad que se está testeando, en este caso la activación de roaming
  • Poscondición: Es lo más importante, porque sin ello no hay manera de generar métricas, es el estado final del sistema luego de invocar una acción.

La herramienta: JBehave en acción

Para transformar el requerimiento en algo concreto se utilizará la herramienta JBehave. Ésta permite desencadenar tests unitarios mediante el uso de reglas como las que se describieron anteriormente, asociando el escenario a un caso de test y las partes a invocaciones de test concretas. En este punto se puede apreciar como al rol del tester se le asignan incumbencias de desarrollador, aunque desde una perspectiva de cliente del módulo de validaciones ya que sólo es necesario conocer su interfaz para poder usarlo, tal como el cliente de la aplicación a la aplicación misma.

Escenarios: Cómo debería comportarse la aplicación

Como JBehave está desarrollado en idioma anglosajón, para describir el escenario anterior es necesario cambiar algunas palabras por su traducción directa

Given Un contrato pospago
When Intento activar el servicio
Then La validación termina sin errores

y guardar esta información en un archivo con nombre ‘validacion_servicio’.

Una vez salvado el escenario, es necesario codificar el caso de test y éste debe tener el mismo nombre que el escenario pero sin ‘_’, entonces se genera la clase ValidacionServicio.

Aunque esta convención parece aleatoria, seguir un patrón de desarrollo definido a priori y cumplirlo al pie de la letra, permite a cualquier sujeto externo al desarrollo entender los casos de test solamente conociendo la herramienta y sus prácticas. Por ejemplo, esta es una posible implementación de ValidacionServicio:

public class ValidacionServicio extends Scenario {

    public ValidacionServicio() {
        super( new PasosDeValidacion() );
    }
}

public class PasosDeValidacion extends Steps {

}

Pasos: Partes concretas del test

Una vez definido el caso de test, lo siguiente es definir qué acciones responden a cada comportamiento especificado por el analista, es decir, los pasos.

Para eso se debe saber que para cada tipo de acción en un escenario hay una anotación correspondiente:

  • Para las precondiciones se utiliza la anotación @Given y la funcionalidad de este método es cargar información al estado del escenario.
  • Para las acciones, la anotación @When, este método está encargado de invocar la funcionalidad a testear
  • En el caso de las poscondiciones utilizamos la anotación @Then, la cual va a permitir definir un método que verifique el estado del escenario y alerte en caso de que no cumpla con lo esperado.

Es importante reiterar que como el desarrollo está gobernado por la necesidad de cumplir con los test, el 99% del tiempo de vida del proyecto más de un test estará incompleto. Teniendo en cuenta esto, se desprende que por más que haya 100 escenarios escritos, la construcción automática del software (la cual también va a generar las métricas de la herramienta de BDD) no puede estar interrumpida por el incumplimiento total o parcial del escenario, para poder permitir entregas parciales. Por eso, en este punto si se corren los tests de los escenarios sin definir todo el comportamiento, las partes incompletas se marcarán como PENDIENTES y la construcción terminará por exitosa. Diferente es cuando un test está completo y falla, lo cual puede suceder haciendo testing de regresión.

En esta parte, el tester necesitará el conocimiento del desarrollador o la ayuda del arquitecto para poder usar el API que permitirá invocar la funcionalidad a testear, generar las precondiciones y evaluar las poscondiciones. Para dicho caso en particular, los pasos de validaciones son los siguientes:

 

    @Given("Un contrato pospago")
    public void crearGestionyContratoPrepago(){
       // ... generar contrato y asociarlo a la forma de pago POSPAGO ...
    }
   
    @When("Intento activar el servicio")
    public void validarActivacion() {
       // ... invocar la validación y obtener el estado de la operación ...
    }
 
    @Then("La validacion termina sin errores")
    public void assertTerminaSinErrores(){
        // ... asegurar o verificar que el escenario cumpla con un estado en particular ...
        ensureThat(!validacionTerminaConErrores);
    }

Una vez generados los tests, las personas con el rol de desarrollador son los encargados generar la funcionalidad necesaria. Esta vez, con requerimientos tan sólidos como la aceptación de un test automático e imparcial, las tareas delegadas son menos ambiguas y mucho más fáciles de auditar.

Interacción entre roles

Al aplicar esta práctica se pueden apreciar los beneficios enseguida que el tester comienza a trabajar sobre el escenario para generar un caso de test exhaustivo:

  • Dado Un contrato pospago
    • ¿Cuántas formas de pago tiene un contrato?
    • ¿Es necesario contar con el cliente para esta validación?
  • Cuando Intento activar el servicio
    • ¿Qué pasa cuando se intenta desactivar el servicio?

Otra vez, el rol del analista para evacuar las incógnitas:

  • Las formas de pago de un contrato son POSPAGO, PREPAGO e HIBRIDO y estas solo se van a tener en cuenta para la activación.
  • La aplicación no puede impedir la desvinculación de un servicio de un cliente, a lo sumo se guardará un historial de desactivaciones

Como la manera de validar el sistema es mediante una muestra ejemplar especificada en las precondiciones, es preciso asegurarse de que estas sean lo mas amplias posibles. Entonces, sabiendo que todas las formas de pagos son POSPAGO, PREPAGO e HIBRIDO se pueden generar los siguientes escenarios:

  • Escenario 1
Given Un cliente cualquiera
Given Un contrato pospago
When Intento activar el servicio
Then La validacion termina sin errores

Given Un contrato prepago
When Intento activar el servicio
Then La validacion termina con errores
 
When Intento desactivar el servicio
Then La validacion termina sin errores
  • Escenario 2
Given Un cliente cualquiera
Given Un contrato hibrido
When Intento activar el servicio
Then La validacion termina con errores
  • Escenario 3
Given Un cliente cualquiera
Given Un contrato prepago
When Intento activar el servicio
Then La validacion termina con errores
  • Escenario 4
Given Un cliente cualquiera
Given Un contrato prepago
Given Un contrato hibrido
Given Un contrato pospago
When Intento desactivar el servicio
Then La validacion termina sin errores

De esta manera se puede apreciar como se están reutilizando los pasos generados en los escenarios anteriores, y al utilizar la característica de secuencialidad de los escenarios se puede generar un test lo suficientemente completo describiendo cómo la aplicación se debería comportar antes de escribir la primera línea de código.

Hay que tener en cuenta que tener muchos tests sobre la misma funcionalidad no brindará una métrica más precisa en cuanto progreso del proyecto pero así mismo este trabajo no es vano, puesto que ayudará definir el comportamiento más extensivamente para que el desarrollador no construya un software que responda sólo a un caso en particular. No por malas intenciones, pero podemos aceptar este archivo con reglas como un elemento de documentación dado a su lenguaje tan coloquial.

Conclusión

Como se pudo apreciar en el ejemplo de caso de uso, aplicar la práctica con JBehave implica un costo muy bajo de adaptación. Solamente resta llevar a la practica la costumbre de generar escenarios de prueba previos al desarrollo y auditar las métricas constantemente para usarlas como referencia de avance.

Un punto en contra (o a favor, dependiendo el punto de vista) es que dicha práctica es relativamente nueva y por ende las herramientas requeridas están en desarrollo y constante cambio, sin que exista aún una en particular como referente.

 

Enlaces

Software Java

Software .Net

Documentación

Ejemplos de utilización

Bibliografía adicional

Las obras que se mencionan a continuación, que aún no han sido publicadas, se consideran útiles para ampliar el contenido del presente artículo.

Anuncios

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 )

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 )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: