Bienvenidos sean a este post, hoy veremos otra forma de desarrollo.
Esta es la abreviatura de Behaviour Driven Development (Desarrollado manejado por conducta), y esta pensado para la comunicacion entre los participantes de un negocio, desarrolladores y un equipo de analisis de calidad. Un proyecto puede tener una serie de inconvenientes como exceder su presupuesto, no cumplir con los plazos, fallar completamente por confusiones o vagos requerimientos, argumentos tecnicos, y/o ciclos de feedback.
BDD es un proceso de desarrollo agil con un conjunto de practicas que apuntan a reducir los huecos/barreras de comunicacion, mas conocido como telefono descompuesto, y actividades desviadoras. Tambien incentiva a los miembros a estudiar ejemplos del mundo real durante el ciclo de vida de produccion. A su vez, contiene dos partes principales: entregar descubrimiento y TDD. Esto permite que las personas en distintas organizaciones y equipos puedan entender la conducta correcta de lo que se esta desarrollando. La fase de entrega de descubrimiento introduce una tecnica de mapeo de ejemplos para que a pesar de tener distintos roles tengan conversaciones a traves de ejemplos concretos.
Estos ejemplos se convertiran en test automatizados y documentacion de como se comporta el sistema para mas adelante. En la fase de TDD, BDD especifica que los test para cualquier unidad de software deberian ser especificos en terminos de la conducta deseada de la unidad.
Hay muchas herramientas de frameworks de BDD (JBehave, RBehave, Fitnesse, Cucumber) para diferentes plataformas y lenguajes de programacion. Estos frameworks por lo general hacen los siguientes pasos:
- Leer un documento de formato de especificacion que esta preparado por un analista de negocios durante la fase de entrega de descubrimiento.
- Transforma el documento en clausulas significativas, cada clausula individual es capaz de ser establecida en tipo de test para los QA. Los desarrolladores pueden implementar codigo fuente desde la clausula tambien
- Ejecuta el test para cada escenario de clausula automaticamente
Con esto podemos resumir que siempre debemos comenzar la recoleccion de requerimientos, luego el diseño, programacion y por ultimo el testeo. Pero debemos tener en cuenta que TDD corta con este concepto, porque despues del diseño usamos al testeo para luego pasar a programar nuestro codigo. En cambio, con BDD nos agrega la comunicacion entre distintos sectores en un framework de TDD y mas enfocado en su conducta.
En resumen, hoy hemos visto a BDD, muy en forma teorica, como se compone, de que se trata,, y algunos detalles a tener en cuenta. Espero les haya resultado de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.


Donación
Es para mantenimento del sitio, gracias!
$1.50
