Etiqueta: bdd

Introducción al Mapeo de Ejemplos (Example Mapping)

Nota: este artículo es una traducción del artículo de Matt Wynne publicado originalmente en inglés en diciembre de 2015 y disponible aquí.

Antes de tomar una historia de usuario para desarrollo, es crucial tener una conversación para clarificar y confirmar los criterios de aceptación.

Alguna gente hace esto durante la reunión de refinamiento de backlog o en sesiones de Planning Poker. Otros equipos hacen reuniones específicas de los tres amigos, talleres de especificación o talleres de discovery.

De cualquier forma que llames a esta conversación, muchos equipos la encuentran difícil, al no ser una conversación estructurada suele llevar mucho tiempo y se torna aburrida. Como consecuencia de ello, algunos no la hacen de forma regular o consistente, o tal vez directamente dejan de hacerla.

He descubierto un método simple y poco tecnológico para hacer que esta conversación sea corta y poderosamente productiva. Lo llamo Example Mapping.

Cómo funciona

Los ejemplos concretos son una excelente manera de ayudarnos a explorar el dominio del problema y constituyen una excelente base para nuestras pruebas de aceptación.

Pero a medida que discutimos estos ejemplos, hay otras cosas que surgen en la conversación que también merecen ser capturadas:

  • reglas que resumen un conjunto de ejemplos o expresan restricciones acordadas acerca del alcance de una historia.
  • preguntas acerca de escenarios en los que nadie en las conversaciones sabe cuál es el resultado correcto. O suposiciones que estamos haciendo para poder avanzar.
  • nuevas historias que descubrimos o slicieamos y diferimos fuera del alcance.

La técnica de mapeo de ejemplos utiliza un paquete de fichas bibliográficas o tarjetas de 4 colores y algunos bolígrafos para capturar estos diferentes tipos de información a medida que se desarrolla la conversación. Mientras hablamos, los capturamos en las tarjetas y los organizamos en un mapa.

Comenzamos escribiendo la historia en discusión en una tarjeta amarilla y colocándola en la parte superior de la mesa.

A continuación, escribimos cada uno de los criterios de aceptación, o reglas que ya conocemos, en una tarjeta azul y los colocamos en la mesa debajo de la tarjeta de historia amarilla.

Para cada regla, es posible que necesitemos uno o más ejemplos para ilustrarla. Los escribimos en una tarjeta verde y los colocamos bajo la regla correspondiente.

Mientras discutimos estos ejemplos, podemos descubrir preguntas que nadie en la sala puede responder. Entonces los capturamos en una tarjeta roja y seguimos con la conversación.

Seguimos adelante hasta que el grupo esté satisfecho de que el alcance de la historia está claro, o nos quedamos sin tiempo.

Y eso es todo. Te lo dije ¡es simple!.

Feedback Instantáneo

A medida que fluye la conversación, creamos rápidamente una representación visual en la mesa frente a nosotros que refleja nuestra comprensión actual de la historia:

  • Una mesa cubierta con tarjetas rojas (preguntas) nos dice que todavía tenemos mucho que aprender sobre esta historia.
  • Una mesa cubierta de tarjetas azules (reglas) nos dice que esta historia es grande y complicada. ¿Quizás podamos particionarla? Tomamos otra tarjeta amarilla (historia), escribimos la nueva historia y la colocamos en el backlog.
  • Una regla con muchos ejemplos podría ser demasiado compleja. ¿Hay múltiples reglas en juego que deben ser objeto de otras historias?

Descubrirás que algunas reglas son tan obvias que no necesitan ejemplos en absoluto. Está claro a partir de la conversación que todos entienden la regla. ¡Excelente! Todos pueden seguir adelante con sus vidas sin obligarse a sí mismos a obtener ejemplos como autómatas con lavado de cerebro BDD.

Pensando dentro de la caja del tiempo (time-box)

Un pequeño grupo de amigos debería ser capaz de procesar una historia bien entendida y de buen tamaño en unos 25 minutos.

Si no puede, o todavía está dominando esto (lo cual está bien), la historia es demasiado grande (definitivamente no está bien) o todavía tiene demasiada incertidumbre. Escuche eso e intente dividir la historia, o deje que la persona de producto se vaya y haga un poco de tarea antes de volver a poner la historia en otra sesión de mapeo de ejemplos en una fecha posterior.

En Cucumber, usamos un voto rápido con la mano después de 25 minutos para determinar si creemos que la historia está lista para comenzar a desarrollarse. Incluso si quedan algunas preguntas pendientes, puede pensar que son lo suficientemente menores como para poder resolverlas sobre la marcha. Deja que el grupo decida.

Beneficios

El mapeo de ejemplos ayuda a acercar y enfocarse en las partes más pequeñas de comportamiento dentro de la historia. Al mapearlo, puede separar las reglas, encontrar el núcleo del comportamiento que se desea y posponer el resto hasta más tarde. Con este nivel de detalle, el mapeo de ejemplos actúa como un filtro, evitando que las grandes historias entren en el sprint y exploten con sorpresas de último minuto tres días antes del día de la demostración.

También ahorra tiempo y, por lo tanto, ayuda a mantener el interés de las personas ocupadas en el proceso.

Muchos equipos asumen que los tres amigos deben escribir pruebas de aceptación (por ejemplo escenarios de Cucumber) durante esta sesión, sentados alrededor de un proyector mientras alguien escribe escenarios formales de Cucumber en un IDE. Hay ocasiones en las que esto es valioso, pero en general creo que es una mala idea. De hecho, puede distraerte del verdadero propósito de la conversación.

Es fácil ver por qué la gente comete este error: el propósito aparente es tomar una historia de usuario, que ya tiene algunos criterios de aceptación predefinidos, y generar ejemplos que puedan convertirse en pruebas de aceptación.

Creo que el verdadero propósito, sin embargo, es llegar a un entendimiento compartido de lo que se necesitará para hacer la historia. Puede moverse mucho más rápido hacia este objetivo si se mantiene bajo en tecnología.

Episodios de Friends

Entonces, en lugar de optar por escenarios formales de Gherkin en toda regla, solo intente capturar una lista de ejemplos aproximados, utilizando la convención de nomenclatura de episodios de Friends.

Por ejemplo:

  • Aquel en el que el cliente olvidó su recibo
  • Aquel en el que el producto está dañado
  • Aquel en el que se compró el producto hace 15 días

A veces, cuando acecha la incertidumbre, instintivamente querrás ser más concreto que esto. Todavía no necesitas recurrir a la estructura rígida de Dado-Cuando-Entonces:

Cuando el resultado (el entonces) no está claro, no tienes un ejemplo, tienes una pregunta.

Incógnitas conocidas

Cada vez que una conversación como esta da vueltas en círculos, es porque no tienes suficiente información. Probablemente falte alguien en la conversación, o tal vez necesites hacer una investigación de usuario, o un spike.

En lugar de dejar que todos compartan su opinión sobre cuál creen que debería ser el resultado, simplemente captura la pregunta y continua. ¡Felicidades! Acabas de convertir una incógnita desconocida en una incógnita conocida. Eso es un gran progreso.

¿Quién debería venir?

Lo mínimo son los tres amigos: un desarrollador, un tester y una persona de producto. Sin embargo, eso es solo un mínimo. Por todos los medios invita a gente de operaciones, personas de experiencia del usuario o cualquier otra persona que sea relevante para la historia que se está discutiendo. Cualquier persona que pueda ayudar a descubrir nuevas preguntas o convertir las preguntas en decisiones durante la conversación será útil.

Mientras aprende esta técnica, puede ser útil tener a alguien en el papel formal de facilitador, cuyo trabajo sea asegurarse de que todo lo que se dice se capture en una tarjeta. Los ejemplos y las preguntas vuelan rápidamente por la sala, y se necesita disciplina para capturarlos en la mesa para que pueda verse de lo que se está hablando.

Entonces ¿cuándo escribimos el Gherkin?

No dejes que esta publicación te confunda: también es de gran valor escribir Gherkin juntos, especialmente durante los primeros días de un proyecto. Ahí es donde desarrollas tu lenguaje ubicuo, y es vital tener esos escenarios expresados ​​de una manera en la que todos en el equipo crean.

Pero expresar ejemplos de esa manera requiere un modo de pensar diferente al de decidir qué ejemplos están en el alcance y aclarar las reglas subyacentes.

Para un equipo que está funcionando, con un lenguaje de dominio bastante maduro, mi preferencia es que la persona del producto dedique su tiempo y energía a la sesión de mapeo de ejemplos y deje la escritura real de Gherkin a sus otros dos amigos. Una vez que han redactado una especificación de Cucumber, la persona del producto puede darles su opinión.

¿Es así como lo habría escrito?

Esto le brinda la oportunidad de probar qué tan efectiva fue la conversación de mapeo de ejemplos para transferir el conocimiento de la persona del producto a sus amigos.

¿Con qué frecuencia debemos hacer esto?

La gente de producto suele estar ocupada. Respeta su tiempo programando estas sesiones de manera que puedan prestarte toda su atención.

Mi recomendación, basada en lo que he visto funcionar para varios equipos en la práctica, es ejecutarlos con frecuencia: cada dos días suele ser un buen ritmo. Solo elige una historia y dale 25 minutos de atención, luego vuelve al trabajo. Tratar de hacer más en un lote grande solo agotará su energía.

¡Pero mi equipo está distribuído!

Ya he visto trucos innovadores en esto: algunas personas usan listas con viñetas en un documento de Google, he visto personas que usan una hoja de cálculo con celdas de colores para representar las tarjetas. También puedes usar un mapa mental. La clave es mantenerlo rápido y fácil de usar, para que puedan concentrarse en la conversación.

Algunas consejos finales

Es importante comprender claramente la distinción entre reglas y ejemplos antes de poder utilizar el mapeo de ejemplos. Tengo un ejercicio divertido para enseñar esto que compartiré en una publicación futura.

Recuerda que todo el propósito de esta conversación es descubrir las cosas que aún no sabes. Así que no hay preguntas tontas. Diviértete y explora realmente el problema.

Descubrirás que las reglas crean fallas naturales para dividir una historia. Trata de sentirte cómodo aplazando tanto como sea posible, para que puedas concentrarte en resolver el núcleo del problema. Puedes agregar más sofisticación (y complejidad) más adelante.

Gracias a Janet Gregory, Aslak Hellesøy y Seb Rose por sus comentarios sobre esta publicación, a Theo England por su paciencia mientras la perfeccionaba y a Tom Stuart por sacarme el dedo.

Recursos de Testing 3.0

Ayer estuve participando en el ciclo de Tech Talks facilitado por Arcadio Abad. Estuve hablando sobre un conjunto de prácticas que he dado en llamar Testing 3.0.

La charla fue efectivamente una charla de ida y vuelta con Arcadio quien a su vez transmitía las preguntas de la audiencia. Me sentí muy cómodo con el formato y creo que pude dar respuesta a todas las preguntas que Arcadio me transmitió(aunque creo que por el chat pasaron algunas otras que pueden haber quedado sin respuesta por cuestiones de tiempo).

Durante la charla hablé de varias cuestiones pero la gran mayoría relacionadas a la idea de usar los tests como especificación de requerimientos y guía del desarrollo (lo que usualmente se conoce como BDD). Comparto aquí algunos recursos al respecto:

  • Los libros de BDD de Rose y Nagy son simplemente excelentes.
  • El libro «Specification by Example» de Goyco también es excelente, es bastante más extenso porque cubre muchas cuestiones.
  • Unos videos que muestran la técnica de BDD/TDD en acción: parte 1 y parte 2
  • Varios artículos de mi blog sobre esta técnica

Y si quieren aprender más de BDD y no tienen un perfil muy técnico, los invito a que se sumen a mi Taller de Prácticas Técnicas para Scrum Masters (al margen del nombre, vemos cuestiones que son relevantes incluso para gente que no es Scrum Master)

Libro: Formulation (The BDD Books)

Terminé de leer este libro hace un par de días. Me gustó y me alegró ver que varias de las cuestiones que menciona coinciden con lo que vengo aplicando en mis proyectos y enseñando en MeMo2.

Al margen de que ya sabía, descubrí algunos conceptos y capacidades de Gherkin de las que nos estaba al tanto como ser los «journey escenarios» y la diferencia entre las «data tables» y «example tables».

El texto está escrito de forma tal que intercala explicaciones conceptuales con fragmentos de diálogos de un equipo de desarrollo que aplica esos conceptos. En cierto modo esto hace que la explicación de cómo formular buenos ejemplos contenga muchos ejemplos.

Creo que es fundamental para todo equipo pretenda aplicar BDD que al menos una persona del equipo de desarrollo maneje fluidamente las cuestiones descriptas en este libro (¿el facilitador/Scrum Master? ¿un tester?).

Sobre el uso de Gherkin/Cucumber y esa costumbre de dormir en la mesa

Toda herramienta es creada con un fin y luego usada como a cada uno le parece. El ejemplo que siempre pongo es el de la mesa: podríamos pensar que la mesa fue pensada para sentarse a comer o a trabajar, pero sin embargo alguien podría usarla para acostarse a dormir. Esto puede traer dos riesgos: 

  1. que no resulte muy cómodo/conveniente o incluso que tenga limitaciones, «¡que incómodo dormir en la mesa! => es razonable ya que no fue pensada para eso»
  2. que posiblemente haya una herramienta más apropiada => ¿qué tal si probas dormir en la cama?

(tengo la sensación de que esta situación de «dormir» en la mesa se repite frecuentemente en la industria del software con distintas herramientas)

En este sentido Gherkin fue pensado como una herramienta de colaboración/comunicación/especificación para ser utilizada de programar la solución y que nos trae el beneficio adicional de poder automatizar utilizando alguna herramienta Gherkin-compatible como Cucumber, Cucumber-jvm, Behat, etc, etc.

Sin embargo vemos en la industria un uso alternativo de Gherkin/Cucumber: la automatización de pruebas una vez que la solución ya está programada. Si bien este escenario esalgo perfectamente válido a mi no me resulta conveniente. O sea: si no vamos a tener el involucramiento del usuario y no vamos a trabajar colaborativamente en entender el negocio antes de empezar a programar y solo buscamos automatizar pruebas, me resulta entonces más práctico programar las pruebas con alguna herramienta de la familia xUnit o Rspec. Un escenario en el que automatizar con Gherkin/Cucumber «a posteriori de la programación» es cuando tenemos una persona describiendo la prueba (erscribiendo Gherkin) y otra persona escribiendo el código de automatización por detrás del Gherkin. En lo personal sigue sin convencerme.

Pero al margen de mis gustos y convicciones, hay una diferencia importante en el uso de Gherkin dependiendo de la intención con la que lo estamos usando. Más concretamente la forma en la que vamos a escribir los escenarios con Gherkin va a ser distinta. Veamos un ejemplo, tomemos una funcionalidad de login, si estamos usando Gherkin como herramienta de colaboración/comunicación/especificación y seguimos las recomendaciones de los creadores, podríamos tener lo siguiente:

Antecedentes:
  Dado que existe un usuario "juan" con clave "claveFuerte123"

Escenario: Login exitoso
  Cuando un usuario ingresa credenciales "juan" y "claveFuerte123"
  Entonces el login exitoso

Escenario: Login fallido por clave incorrecta
  Cuando un usuario ingresa credenciales "juan" y "claveIncorrecta"
  Entonces el login es fallido

Algunos puntos para destacar:

  • El foco está en el comportamiento omitiendo todo detalle de implementación
  • No hay ninguna mención a elemento de presentación/pantallas/html
  • Los escenarios son muy cortos

Veamos ahora una versión alternativa que típicamente podría ser creada «post-programación» con el fin de automatizar una prueba de regresión.

Antecedentes:
  Dado que existe un usuario "juan" con clave "claveFuerte123"

Escenario: Login exitoso
  Dado que en el campo "usuario" pongo "juan"
  Y que en el campo "clave" pongo "claveFuerte123"
  Cuando hago click en el "Login"
  Entonces veo el mensaje "Bienvenido"

Escenario: Login fallido por clave incorrecta
  Dado que en el campo "usuario" pongo "juan"
  Y que en el campo "clave" pongo "claveIncorrecta"
  Cuando hago click en el "Login"
  Entonces veo el mensaje "Credenciales incorrectas"

A diferencia del otro caso aquí vemos mención a los elementos de presentación/pantalla y un detalle «del cómo», esto se debe a que el escribir el Gherkin de esta segunda forma permite reutilizar código de automatización. O sea, el paso «Dado que en el campo <x> pongo <v>» es completamente genérico y lo puedo utilizar tanto en el escenario de login como en cualquier otro. Por otro lado el paso «Cuando un usuario se logueo con credenciales «juan» y «unaClaveIncorrecta» es muy específico del login.

Entonces:

  • En un contexto donde el objetivo central es la automatización, será mucho más probable encontrarnos con Gherkin del segundo estilo.
  • En un contexto donde el objetivo es entender/comunicar será más probable (y conveniente) el uso de Gherkin del primer estilo.

Estos dos estilos de Gherkin que menciono aquí son en cierto modo dos extremos. Asimismo, si bien la sintáxis de Gherkin no viene sufriendo grandes cambios, la forma de uso ha ido variando dado pie a distintos estilos. Lo importante para mi es que cada equipo establezca explícitamente un conjunto de convenciones sobre su uso que estén en sintonía con el uso que le vayan a dar.

Para aquellos que apuesten a utilizar Gherkin como herramienta de colaboración/especificación les recomiendo la serie de libros de Rose y Nagy «The BDD Books«.

Libro: Discovery (The BDD Books)

Ayer terminé de leer este libro cuyo nombre completo es «Discovery: Explore behaviour using examples«. Es el primer libro de la serie «The BDD Books» de Seb Rose y Gaspar Nagy. El foco del libro está en la utilización de ejemplos como «técnica de especificación funcional». En este sentido el libro provee una guía respecto de cómo, quien y cuando utilizar la técnica, dando respuesta no solo a las particularidades de la técnica sino también a cómo usar la técnica en el contexto de un proceso de desarrollo de una equipo/organización.

Debo decir que el libro me gustó mucho, es cortito y muy concreto. Provee ejemplos muy claros y fáciles de entender. Al mismo tiempo atiende dudas/situaciones que habitualmente surgen al intentar aplicar BDD en distintos contextos de proyecto.

Si bien mi referencia preferida en este tema son los libros de Gojko (Specification by Example y Bridging the Communication Gap), creo que este libro es más directo y por ello que puede resultar un muy buen punto de entrada para quienes no están familiarizados con la técnica. Claro que los libros de Gojko son mucho más amplios y profundos pero justamente por eso me parece que es mejor arrancar por aquí y eventualmente continuar con los otros.

El libro está disponible en LeanPub.

Cucumber modo dual

Cucumber es la «herramienta insignia» de BDD. Permite escribir ejemplos (pruebas) ejecutables utilizando Gherkin, una sintaxis amistosa para gente no técnica.

Una de las particularidades de Cucumber es que provee una muy buena experiencia para el desarrollador pues tiene la capacidad de instanciar dentro del mismo proceso la ejecución de la pruebas y la aplicación a probar incluso cuando la aplicación bajo prueba es una aplicación web[*]. Esto tiene algunas implicancias interesantes como ser:

  1. Las pruebas corren mucho más rápido (comparado a si corrieran pruebas y aplicación en procesos separados) lo cual se traduce un feedback más rápido para el desarrollador
  2. Es posible desde las pruebas acceder el estado interno de la aplicación simplificando las tareas de setup (Given/Arrange) y verificación (Then/Assert) de las pruebas

Es importante tener presente que estas dos cualidades pueden traer también algunas complicaciones (pruebas inconsistentes, resultados incorrectos, etc) sino no se toman ciertas precauciones al momento de automatización de las pruebas.

Resulta interesante tener presente que si escribimos nuestras pruebas con cierta precaución en el uso de 2 (o sea: si evitamos acceder el estado interno de la aplicación por fuera de su interface pública) podemos entonces utilizar el mismo set de pruebas para probar la aplicación ya instalada en un ambiente de prueba.

Tenemos entonces dos usos posibles de Cucumber: 

  1. Como herramienta del programador, utilizándola en su máquina local para guiar su desarrollo y obtener feedback instantáneo de la ejecución de los ejemplos acordados con el usuario
  2. Como herramienta para ejecutar las pruebas de aceptación y regresión en un ambiente de prueba, siendo estas pruebas las mismas que el programador utilizo para guiar su desarrollo

Si bien en este caso estoy hablando de Cucumber (ruby) estas cuestiones que menciono también aplican a otros frameworks/tecnologías.

Mientras termino de escribir estas línea me doy cuenta que para entender mejor este tema puede resultar muy conveniente ver algo de código, por ello en los próximos días estaré publicando un video mostrando ejemplos de código.

[*] esto en parte tiene que ver con capacidades de Cucumber pero también con las abstracciones y capacidades de otras herramientas del stack de Ruby como Rack.

Preparandome para XP 2015

A fin de mes voy a estar viajando a Helsinki para participar de la conferencia XP 2015, donde además de disfrutar de la conferencia como asistente, estaré participando como orador/facilitador dos sesiones.

La primera de ellas es una sesión del tipo Technical Demo en la que estaré mostrado Octopush, una herramienta open source que desarrollamos con la gente de OLX para orquestrar deployments en contextos de entrega continua.

La segunda sesión que estaré facilitando es un taller de Behaviour-Driven Development. El taller está dividido en partes, la primera con foco en el flujo de trabajo y en las cuestiones de colaboración/comunicación y la segunda con foco en las cuestiones técnicas. Para esto último utilizaremos una máquina virtual con todas las herramientas ya instaladas de cara a poder utilizar mejor el tiempo del taller y no perder tiempo en instalación y configuración.

xp2105

Preparando el tutorial de BDD para XP 2015

En los últimos meses publiqué un serie de posts sobre BDD que fuí escribiendo mientras preparaba un curso en formato tutorial para dictar en la conferencia XP 2015 en Helsinki (Finlandia).

Durante semana Santa terminé de armar el curso y este viernes voy a dictarlo por primera vez para obtener feedback y así poder ajustarlo de cara a la conferencia.

Dado que la dinámica es hands-on, decidí armar una máquina virtual para simplificar el setup en las máquina de los asistentes. Esta vez la máquina virtual la preparé tomando como base una imagen de Lubuntu que es básicamente un Ubuntu con un sistema de ventanas muy liviano y con layout muy parecido al de Windows 7.

El tutorial está enfocado en las cuestiones técnicas de BDD: qué herramientas utilizar, como integrarlas en un proceso de integración continua, cómo hacer para para que los usuarios puedan agregar ejemplos y puedan ejecutarlos sin necesidad de instalarse todo el stack de desarrollo, etc, etc.

La semana próxima les cuento que tal anduvo.

BDD, ATDD y SBE ¿es todo lo mismo?

En la actualidad nos encontramos con estos 3 acrónimos que en muchas ocasiones son utilizados como sinónimos y cuya diferencia no es del todo clara. Más aún, en Una Mirada Ágil los mencionamos a modo informativo sin entrar en mayor detalle pues consideramos que en esencia todos apuntan a lo mismo: la importancia central del trabajo colaborativo entre técnicos y la gente del negocio para especificar la funcionalidad a construir utilizando ejemplos concretos. Y también todas ponen el aspecto colaborativo por encima del aspecto técnico (ejecución automatizada).

Personalmente creo que las principales diferencias radican en que cada uno de estos términos surgió como consecuencia de distintas líneas de trabajo que se desarrollaron en paralelo con distintos protagonistas, todos ellos trabajando principalmente desde la industria y bajo un paradigma de desarrollo ágil. Más allá de los argumentos que pueda tener cada uno de los protagonistas para insistir con su terminología creo que adicionalmente hay una cuestión natural de «orgullo» (y posiblemente también de negocio/marketing) que en cierto modo dificulta la unificación de terminología. Como suele decirse: «Cada maestro con su librito».

Más allá de esto quisiera dedicar algunas líneas a cada propuesta en particular:

Behaviour-Driven Development (BDD)

Este es el término posiblemente más utilizado en la actualidad, muy asociado a la familia de herramientas Cucumber y cuyo mayor referente es Dan North. El mismo North define BDD como:

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. 

Resalto aquí el hecho de considerar BDD una metodología lo cual es posiblemente la mayor diferencia (a nivel de marketing al menos) con las otras técnicas.

Acceptance Test-Driven Development (ATDD)

Sin duda el punto inicial de todo esto fue TDD, cuya concepción original por Kent Beck era levemente distinta a la actual. Inicialmente Beck hablaba tanto de prueba unitarias como de usuario (customer tests en términos de XP), pero con el correr del tiempo el término TDD fue tomando una connotación unitaria, o sea, en la actualidad TDD se interpreta casi exclusivamente como UTDD (Unit Test-Driven Development). De ahí la necesidad de utilizar el término ATDD para referirse explícitamente a un ciclo de más alto nivel en el cual está involucrada la gente de negocio. Una curiosidad es que Beck en su libro TDD by Example menciona ATDD, pero como acrónimo de Application Test-Driven Development en lugar de Acceptance que es el término utilizado en la actualidad.

Specification by Example (SBE)

Este es el término impulsado por Gojko Adzic y personalmente es el que más me gusta. No porque proponga algo muy distinto, sino simplemente por la terminologia que propone. En el prefacio de su libro Specification by Example Gojko propone una terminología y explica porque la terminología alternativa comúnmente utilizada no le resulta apropiada.

Finalmente no quiero dejar de mencionar que hay algunos otros términos que también suelen utilizarse como sinónimos y que en esencia son lo mismo pero cuya popularidad es mucho menor. Entre ellos se encuentran Story Test Driven Development (STDD) y Example-Driven Development (EDD).

BDD, ATDD y SBE ¿es todo lo mismo? Si.

Breve historia de las herramientas BDD – parte 2

En un artículo anterior conté una parte historia, he aquí la otra.

Mientras que Dan North y los suyos trabajaban sobre JBehave y afines que luego llevarían al surgimiento de Cucumber, Ward Cunningham trabajaba en cuestiones relacionadas a pruebas de aceptación.

El trabajo de Cunningham se tradujo concretamente en una herramienta llamada FIT: Framework for Integration Testing, cuyos objetivos pueden resumirse como:

  • Ayudar a pensar y comunicar las necesidades que debe cubrir una aplicación de software en base a ejemplos concretos de uso
  • Probar automáticamente desde una perspectiva de negocio que una aplicación de software hace lo que efectivamente se espera de ella y que continúa haciéndolo a medida que crece en funcionalidad

Para lograr esto, FIT propone escribir los ejemplos con herramientas capaces de generar HTML (Word, Excel, etc) utilizando distintos tipos de tablas para dar cierta estructura unificada a los ejemplos y facilitar así su interpretación. Una vez escritos los ejemplos trabajando en conjunto con gente de negocio y técnicos, se escribe código Java que interpreta la tablas e interactúa con la aplicación en cuestión.

El propio Ward Cunningham escribió la primera implementación FIT en Java, mientras que tiempo después James Shore tomó la coordinación general del proyecto y colaboró en la implementación en C#.

En 2005 Ward Cunningham junto con Rick Mugridge publicaron el libro Fit for Developing Software: Framework for Integrated Tests, el cual explica de forma bastante detallada el uso de FIT.

A lo largo del tiempo han ido surgiendo diversas herramientas en el ecosistema FIT, algunas de las cuales se integran con FIT mientras que otras lo extienden. Una de las más destacadas es FitNesse, desarrollada por inicialmente por Robert Martin y que en cierto modo agrega una interface de usuario por encima de FIT permitiendo que los ejemplos sean escritos en una Wiki. De esta forma FitNesse oficia de interface de usuario y FIT de motor de ejecución. Esta combinación tuvo buena recepción en la comunidad y para 2006 David Chelimsky y Mike Stockdale ya habían publicado una implementación de FIT en C#.

Fue a partir de esa implementación en C# que en 2008 Gojko Adzic publicó el excelente libro Test Drive .NET Development with FitNesse. Si bien este libro tiene un foco técnico, el autor resalta la importancia del trabajo colaborativo en entre gente de negocio y técnicos para la identificación y especificación de ejemplos. Los siguientes libros de Gojko se centraron precisamente en estas cuestiones de colaboración dejando de lado las cuestiones técnicas.

Fuentes: