Desarrollo dirigido por comportamiento o Behaviour-Driven Development, está basado en TDD pero formalizando los buenos hábitos de los mejores en TDD. Una de las mejores prácticas de desarrolladores que utilizan TDD es escribir las pruebas de aceptación desde el punto de vista del usuario. En BDD, se tiene cuidado de escribir las pruebas de aceptación como un ejemplo que cualquiera pueda leer. Se utiliza este proceso para recibir una retro alimentación por parte de los usuarios de negocio sobre aquello que se debe construir antes de iniciar el desarrollo. De esta forma se presentan las pruebas de aceptación en un lenguaje universal denominado lenguaje ubicuo.
Lenguaje Ubicuo
Muchos proyectos de software tienen problemas, básicamente por la dificultad de entendimiento entre los usuarios de negocio y los desarrolladores.
Los expertos del negocio utilizan una jerga particular para describir el negocio, la cual inicialmente no es sencilla de entender por el equipo de desarrollo y sobre la cual inicia con un entendimiento vago.
Con esfuerzo, el equipo de trabajo desarrolla un lenguaje ubicuo para el proyecto, el cual es entendido tanto por el equipo de trabajo, como por los usuarios. En UML por ejemplo, este lenguaje ubicuo está plasmado en el artefacto denominado Glosario de Términos. Cuando el equipo utiliza este lenguaje en forma consciente en las conversaciones, documentación y el código, los malos entendidos entre el equipo de desarrollo y los usuarios de negocio disminuyen o desaparecen.
Existen herramientas que nos ayudan a realizar este tipo de desarrollo, como el caso de Cucumber. Cucumber interactúa en forma directa con el código del programador, pero utiliza un lenguaje intermedio que los usuarios de negocio pueden entender. De acuerdo a como se trabajan las pruebas de aceptación, en donde existe un trabajo en equipo entre los usuarios de negocio y el equipo de desarrollo, no sólo el equipo de desarrollo decide que funcionalidad se debe implementar luego, además aprenden como se describe dicho comportamiento en un lenguaje común que todos entienden.
Ejemplo:
Lo que hace a Cucumber una buena herramienta es que está diseñado específicamente para asegurarse de que las pruebas de aceptación sean fáciles de leer y escribir por cualquier integrante del equipo. La facilidad de lectura de las pruebas de aceptación escritas con Cucumber, hacen que los usuarios de negocio se involucren más y mejor en esta etapa, ayudando al equipo de desarrollo a entender los requerimientos.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Feature Ingresar al sistema El ingreso debe ser rápido y amigable Scenario Ingreso satisfactorio Los usuarios nuevos deben recibir un correo de confirmación y debe ser confirmado por el website una vez ingresado. Given Tengo que tener la opción para ingresar When Ingrese con la información valida Then Se recibe un correo de confirmación And Debo recibir un mensaje personalizado Scenario Email duplicado Cuando tratan de crear una cuenta con un correo existente. Given Tengo que tener la opción para ingresar When Intento ingresar con un correo que ya existe Then Debo recibir un mensaje de que el correo ya existe And Se presenta la opción de recuperar la clave |
Escribir este tipo de pruebas de aceptación es más que sólo pruebas, se convierte en especificaciones ejecutables.
