Behavior driven development

by Gastón Ramos

Dado que he visto en algunos blog el tema este de “BDD”, voy a ver de qué se trata esto del desarrollo guiado por comportamiento.

Behavior driven development (BDD) Es una técnica de programación que cuestiona el comportamiento de una aplicación antes y durante el proceso de desarrollo. Mediante preguntas tales como “Qué debería hacer esta aplicación?” o “Qué debería hacer esta parte?” los desarrolladores pueden identififcar brechas en la comprensión del problema del dominio y hablar con sus pares o expertos del dominio para econtrar las respuestas.

Mediante el enfoque en el comportamiento de las aplicaciones, los desarrolladores intentan crear un lenguaje común entre todos: gestión, usuarios, desarrolladores, jefe de proyecto y expertos de dominio.

El propósito es cuestionar cada parte de la aplicación y la aplicación entera. Estas cuestiones no tratan meramente características técnicas o requerimientos sino con características relacionadas con el tiempo y costo. Es factible para nuestra organización construir una aplicación de este ámbito? es una pregunta que se puede responder escribiendo tests de comportamiento. Exponiendo las complejidades de antemano, desarrolladores y jefes de proyecto pueden realizar mejores estimaciones de cómo ajustar la organización para manejar la creación de una aplicación.

Para demostrar el comportamiento de una aplicación durante y después del proceso de desarrollo el código es testeado a traves de tests de comportamiento. Estos tests deberían responder las preguntas de la organización acerca de la aplicación e ilustrar como funciona.

Cuando los desarrolladores escriben tests de comportamiento están asumiendo resolver las cuestiones más críticas o importantes primero. Cada test que se escribe trata con la cuestión más importante siguiente en la lista. Si cada cuestión esta resuelta, el comportamiento de la aplicación está definido en los tests y la aplicación ha sido creada.

Los tests de comportamiento usan la técnica del desarrollo guiado por pruebas (TDD – Test Driven Development) pero tienen una meta más específica. El propósito es definir el comportamiento de una aplicación más que su implementación.

Reglas prácticas a seguir:

Cuando se escriben tests de comortamiento hay un número de reglas prácticas para tener en mente que ayudará a los desarrolladores a mantenerse en el camino del testing del comportamiento en vez de la implementación. Estas reglas apuntan a crear el código y diseño de la aplicación tan flexible y robusto como sea posible.

* Tamaño del test: Cada test (Método de test) no debería tener más de 15 líneas de código (sin contar las líneas en blanco).Los tests que son largos o demasiado complejos (O la implementación es ineficiente) o que hacen muchas cosas. Los tests pequeños son más expresivos, hacen más fácil la comprensión de lo que se está testeando y son más fáciles de mantener y refactorizar (refactoring).

* Objetos Mock: El uso de los objetos mock es alentado para alcanzar las metas mencionadas más arriba, estos objetos hacen los tests más precisos, más cortos y fáciles de mantener.

* Métodos ayudantes: Algún comportamiento está mejor implementado en un método ayudante ( ej: cargar esto o aquello desde la base de datos) que puede ser fácilemnte testeado y llamado desde otra aprte en la aplicación. Estos métodos ayudan a escribir código más expresivo y fácil de testear.

* Sin dependencias: Los test de comportamiento no deberáin depender de otros test cases, ni de la ejecución de otros tests o la presencia de cualquier configuración de sistema. Esto asegura sólo un limitado comportamiento bien-definido de una manera granulada muy fina. Lo opuesto es testear una aplicación completamente configurada en un granulado tosco.

* Aislado: Los test de comportamiento deberían funcionar con un aislamiento completo para asegurar sólo una parte muy limitada del comportamiento de una aplicación que es testeada.

* Paquetes: los tests deben estar en un árbol de código separado, pero en el mismo paquete, para permitir un mejor testeo.

* Métodos protegidos: Los métodos ayudantes que implementan comportamiento que debe ser testeado deberían estar declarados con un acceso protegido para permitir la invocación desde los tests case.
fuente: http://en.wikipedia.org/wiki/Behavior_driven_development

Framework BDD en ruby: http://rspec.rubyforge.org/