En un artículo anterior sobre la calidad interna y externa del software plantee la importancia de la testeabilidad para la calidad de un sistema. Reforzando el mensaje: cuando se aumenta la testeabilidad del software, mejoras directamente tu arquitectura y tu diseño. Desarrollar sin pruebas unitarias automatizadas y sin pruebas de aceptación es simplemente, construir código legado desde el momento cero!
En el artículo comenté sobre las estrategias para mejorar la calidad y facilidad de mantenimiento, entrando brevemente en la forma de hacerlo. En este artículo voy a hablar más de cómo hacer, tratando sobre técnicas de desarrollo de software modernas y herramientas para apoyarlas, Behavior Driven Development (Desarrollo Guiado por el Comportamiento) y Acceptance Test Driven Development (Desarollo Guiado por las pruebas de aceptación).
El Behavior Driven Development (BDD) original fue descrito por Dan North en su artículo Introducing a BDD. BDD es similar a Test Driven Development (TDD), aunque es diferente en algunos puntos sutiles, pero cruciales. Por las convenciones de TDD los métodos y las clases de pruebas reciben nombres basados en las clases de producción. BDD reorienta el enfoque al comportamiento del sistema. BDD usa una plantilla para poder pensar en el comportamiento de las pruebas del código:
Dado (Given), un contexto inicial
Cuando (When) un evento se produce
Entonces (Then) asegure algunos resultados.
El ejemplo del artículo de Dan North es bastante ilustrativo. Supongamos la siguiente historia de usuario (user story):
Como un cliente, quiero sacar dinero del cajero automático, de modo que no necesite pasar tiempo en la cola.
¿Cómo podemos saber si esta historia está lista (el concepto de «hecho»)? Hay varios escenarios a considerar. Algunos ejemplos: que la cuenta tenga crédito, la cuenta no tiene mas límite de crédito. Usando la plantilla de arriba el escenario 1 sería ese:
Escenario 1: Cuenta tiene crédito
Dado que la cuenta posee crédito
Y la tarjeta es válida
Y el cajero automático tiene dinero
Cuando el cliente pide dinero
Entonces, asegurare que la cuenta sea debitada
Y asegure que el dinero sea entregado
Y asegure que la tarjeta sea devuelta.
¿Qué significa este cambio en nuestras pruebas unitarias? Cambia, ya que podemos utilizar una herramienta como JBehave*** para desarrollar las pruebas en el formato Dado/Cuando/Entonces (Given / When / Then). La prueba unitaria está girando para el comportamiento en lugar de limitarse a probar los métodos.
Sin embargo, para equipos con experiencia y ya acostumbrados con TDD tal vez ese cambio tenga repercusiones. Para los equipos nuevos será más complejo que una simple prueba unitaria. Por lo tanto, en mi opinión, la mayor ganancia de Behavior Driven Development está cuando ella es unida con la técnica de Acceptance Test Driven Development (ATDD).
Según Koskela, en su libro “Test Driven: Practical TDD and Acceptance TDD for Java Developers”, el TDD puro ayuda a los desarrolladores de software a producir código de mejor calidad y facilidad de mantenimiento. El problema es que los clientes rara vez se interesan en el código. Ellos quieren que los sistemas sean más productivos y generen retornos sobre la inversión. El ATDD ayuda a coordinar los proyectos de software de forma de entregar lo que el cliente desea.
Las pruebas de aceptación son especificaciones de comportamiento y funcionalidad deseados para un sistema. Ellos nos informan cómo, para una determinada historia de usuario o caso de uso, el sistema trata determinadas condiciones y entradas. Nuevamente según Koskela, una buena prueba de aceptación debe ser:
- Propiedad de los clientes
- Escrito en conjunto con los clientes, desarrolladores y analistas de prueba
- Sobre el Qué y no sobre el Cómo
- Expresada en lenguaje de dominio del problema
- Conciso, preciso y sin ambiguedades
Hasta aquí hemos descrito una prueba de aceptación que podría simplemente estar dentro de un documento Word o una planilla Excel. Entonces, ¿cuál es la diferencia de la prueba de aceptación tradicional para la prueba de aceptación "clásica"? En primer lugar es que en ATDD la prueba debe ser automatizada. Este es un punto escencial realizar las pruebas regresivas contínuas. En segundo lugar, las pruebas de aceptación son escritas ANTES de la funcionalidad. Pero, ¿cómo? siguiendo los pasos a continuación:
- Tome una historia o flujo de caso de uso
- Escriba las pruebas de aceptación en el lenguaje de dominio del cliente
- Automatice las pruebas de aceptación
- Implemente la funcionalidad.
Es claro que las herramientas direccionadas a ATDD ayudarían. Tenemos varias open source en el mercado, tales como:
Y, por último, la más interesante que voy a comentar un poco más: Concordion.
¿Qué pasa si usted encuentra una herramienta que puede leer una especificación de un caso de uso, de una historia o de una prueba de aceptación escrita en el lenguaje común y ejecutase esos pasos en su sistema automáticamente? Pues sí, existe esta herramienta, es open source y su nombre es Concordion. Ella es un framework que permite transformar una descripción de requisitos en lenguaje natural (castellano, portugués...) en una prueba automatizada, algo conocido como especificación activa. Por lo tanto, una especificación que se hace aún más útil, porque de ella se pueden ejecutar pruebas automatizadas!
¿Cómo funciona? Básicamente se escribe una especificación en un HTML simple, con comandos ocultos que definen el comportamiento de las pruebas. La instrumentación de esta especificación se realiza mediante una clase Java que acompaña cada especificación y actúa como intermediario entre la especificación y el sistema bajo prueba.
Para algunos ejemplos sencillos e interesantes basta estudiar el tutorial de Concordion.
Otro punto interesante de Concordion es que se puede ejercitar directamente el código de la capa de aplicación o de negocios o entonces usar una API que navegue páginas Web. En el sitio de Concordion recomiendan el uso de WebDriver.
Por el momento es esto. Espero que haya ayudado a aclarar la importancia de BDD y de ATDD para mejorar la calidad y la arquitectura del software. Esperamos sus dudas y/o comentarios.
