TDD, BDD, ATDD,sus orígenes y diferencias

Hoy en día, sin lugar a duda, sabemos los beneficios que nos ofrece utilizar TDD en nuestros desarrollos. Del mismo modo, también conocemos bastante bien que Behavior Driven Development es un enfoque interesante para combinar con TDD. Algo que suele quedar más oscuro es  ATDD (Aceptance Test Driven Development) ¿Habías escuchado alguna vez hablar de ATDD? En este post veremos los orígenes de TDD, ATDD y BDD, así como sus diferencias.

TDD_ATDD_HISTORY

La época clásica proviene del sector espacial

Entre 1959 y 1963 se estaba desarrollando el software para el programa Mercury. Se trataba del primer programa de vuelo espacial tripulado por humanos de los Estados Unidos. Toma el nombre del dios romano Mercurio y su objetivo era poner a un humano en órbita y devolverle a la Tierra a salvo.

Se seleccionó como sistema informático el IBM 7090 que era un computador de gran tamaño (Mainframe), el cual funcionaba con tarjetas perforadas.

El hecho es que este tipo de computadoras tardaban tanto en ejecutar que empezaron a realizar pruebas de cada una de las sentencias para, tras su ejecución, poder verificar que los resultados habían sido correctos. Esto se empezó a considerar una buena práctica: realizar las pruebas antes que la codificación o más bien durante la propia codificación. Esto se le llamó Test First y fue descrito en aquella época por el visionario Gerald M. Weinberg en su libro Computer Programming Fundamentals.

Los 90’s fueron el renacimiento del desarrollo software

En 1989 Kent Beck recordaba haber leído el libro Computer Programming Fundamentals cuando le estaba dando vueltas a como mejorar con buenas prácticas el desarrollo de un software de nóminas para Chryslter . Piensa que con la tecnología actual de los 90 podría irse un poco más allá. Este proyecto es el Chrysler Comprehensive Compensation project y sus primeros pasos fueron tan desastrosos que motivaron a Kent Beck hacia búsqueda de una manera diferente de desarrollar software. Una manera basada en unos valores que chocarían con las prácticas habituales.

En 1994, Kent Beck,  escribe la primera versión de sUnit (precursor de la familia xUnit) con la idea de hacer Test Driven Development. En estos años se desarrollan las prácticas de Extreme programming y en 1999 se publica el primer libro de XP (Extreme Programming explained).

En el año 2000 se funda www.junit.org por Object Mentor (Empresa de Robert C. Matin – Uncle Bob) y se creaba el concepto de xUnit como familia de frameworks de test unitarios.

Empieza el siglo XXI y el foco es agile

En 2001 17 críticos , entre ellos Kent Beck, del modelo tradicional de desarrollo software se reúnen en Snowbird (Utah). En esta reunión surge el término “métodos ágiles” para definir aquellos “métodos” que surgían como alternativa a otros considerados muy pesados y rígidos por su carácter normativo. Principalmente críticas a Waterfall (Modelo en Cascada).

De aquí surgieron unos principios y valores que compartían todas aquellas metodologías que empezaron a denominarse en ese momento “ágiles” en contraposición a aquellas más “pesadas”. Se empezó a conocer más  Scrum, Crystal, FDD, Extreme programming (XP)  como alternativas a las metodologías “pesadas” que eran vistas como recetas que hay que seguir al pie de la letra. Si es cierto que todavía se sigue utilizando mal el término “metodología”, quizá por inercia, pero todas estas “metodologías ágiles” no son recetas sino conjuntos de buenas prácticas que suelen combinarse entre ellas para crear una metodología concreta. Por eso TDD, que es una práctica de XP, se empieza a utilizar en la mayoría de las metodologías ágiles, surgiendo la necesidad de consultores y formadores como Dan North, del que hablaremos un poco más adelante.

Ward Cunningham es un ingeniero software que desarrolló la primera Wiki. Es un pionero de los patrones de diseño y de XP junto con Kent Beck.  Se trata de un ingeniero que visto florecer TDD desde sus inicios, y al darse cuenta de que hay un vacío metodológico entre la descripción de la necesidad de usuario y el comienzo de desarrollo mediante TDD, piensa en una solución y surge Fit (Framework for Integration Tests) en 2002. En 2005 Robert C. Martin mejoró esta herramienta creando Fitneese.  La metodología utilizada junto con estas herramientas es ATDD (Aceptance Test Driven Development)  la cual está pensada para combinarse con TDD.

Casi al mismo tiempo (2006-2009) surgió JBehave con el objetivo de combinarse con TDD. Se trata del primer framework para aplicar una técnica llamada BDD.  Esta técnica fue nombrada por primera vez en el blog de Dan North. Dan North fue más allá creando un lenguaje de especificación que modelaba el comportamiento (Gherkin). Esta técnica empieza a ser útil para mejorar la comunicación entre aquellos que definen el qué (historias de usuario) y los que implementan el cómo mediante TDD. Además fomenta la aparición de un lenguaje ubicuocomún entre desarrollo y negocio, algo que se potencia con DDD.

¿Pero cuál es la diferencia entre ATDD, BDD y TDD?

TDD (Test Driven Development) es una técnica de desarrollo que se basa en Test First y Refactoring. La técnica se basa en comenzar creando una prueba unitaria que cubra “aquello que queremos implementar”. Esta prueba inicialmente fallará, por lo que debemos ir modificándola y creando el código (Clases y métodos) que vamos necesitando hasta que la prueba funciona.  Una vez la prueba ha funcionado realizamos una refactorización y volvemos a crear otra prueba unitaria que cubra otro aspecto de “aquello que queremos implementar”. Se trata de un proceso iterativo e incremental a través del cual el diseño emerge. Hay mucho más por detrás, pero creo que es un resumen bastante aproximado de la técnica.

Como observáis, no hemos hablado de requisitos, historias de usuario o criterios de aceptación, sino de “aquello que queremos implementar”. El desarrollador con TDD está pensando en el “cómo” basándose en el “qué”. Esto hace que tenga que hacer el ejercicio de diseñar una solución para que ese “qué” sea cubierto por su “cómo”. Lo normal en estos casos es que la historia de usuario sirve como guía de conversación para resolver el problema, pero la comunicación no era efectiva del todo debido a que negocio y desarrollo no suelen hablar el mismo lenguaje, a veces no hay una comunicación fluida, etc. Este vacío se salva con ATDD.

ATDD (Acceptance Test Driven Development) es una metodología de desarrollo que fomenta la comunicación entre los clientes, los desarrolladores y los testers. Podríamos utilizar frameworks como fit, fitness, cucumber o simplemente un framework xUnit para implementar esta técnica. ATDD se basa en que las necesidades de usuario son cubiertas con escenarios (llamados ejemplos) que son el pegamento entre lo que debe hacerse y cómo debe hacerse. A medida que esas pruebas se crean nos faltan piezas, empezamos a pensar en “aquello que queremos implementar” y aplicamos TDD.

Por otro lado, BDD (Behaviour Driven Development) es una técnica que emerge para complementar TDD como una necesidad. Mientras que ATDD  no habla de comportamiento ni lenguaje ubicuo. BDD permite especificar un comportamiento utilizando un lenguaje casi natural denominado Gherkin. Esas especificaciones, automáticamente se convierten en pruebas. BDD se puede aplicar cuando hacemos ATDD, es decir, uno es técnica y otro es una metodología.

Las diferencias entre ATDD y BDD pueden ser un poco confusas. Existe un libro bastante conocido Specification by Example, que dice que ATDD,  BDD y otros términos, son distintos nombres para referirse a la misma metodología. Por cierto, un libro muy recomendable que habla en detalle de las prácticas y de todo el proceso de ATDD. Por otro lado, otro libro conocido ATDD by Example coincide, añadiendo que también podemos conocerlo con el nombre de Specification by Example, Story Testing o Agile Acceptance Testing.

BDD y ATDD

Mi humilde opinión

Para mi, resumiendo mucho, podríamos decir que TDD  es una práctica de diseño a nivel de clases de la que emergen test unitarios. BDD es otra práctica que se va a ocupar de las pruebas funcionales donde vamos a tener unas especificaciones o documentación viva con un idioma que es entendible por los usuarios (lenguaje de negocio). La forma de construir estas especificaciones, creadas en formato de ejemplos, se debería realizar de forma colaborativa utilizando por ejemplo la técnica de los tres amigos donde se reúne alguien de negocio, alguien de desarrollo y alguien de pruebas para construir estos escenarios juntos ya que BDD fomenta la conversación sobre todo combinado con example mapping.

ATDD se centra aun mas en profundizar en discernir que lo que se esta haciendo no solo se hace en forma correcta, sino que también es lo correcto a hacer. Para llevar a la práctica ATDD podríamos utilizar BDD o no.

Aunque este es mi punto de vista, hay mucho debate sobre las diferencias. Podéis echar un vistazo aquí y aquí.

Además en cuanto a TDD y BDD, mucha gente comenta que para ellos es lo mismo. Para mi eso es bastante dicutible y seguramente la explicación merecería un post completo. Para mi, no son lo mismo y si lo son, y esto depende de tu punto de vista. Existen 2 escuelas conocidas de TDD, una es la clásica y otra es la llamada Mockista (escuela de Chicago y escuela de Londres). Son dos tendencias distintas de hacer TDD donde la escuela Mockista, se centra más en el comportamiento y la clásica en el estado del objeto.

Para los mockistas todo gira en base al comportamiento de los objetos ergo todo es BDD, los clásicos te dirán que no. Dicho esto, quizá tenga que escribir un post para hablar en más profundidad de este tema, ya que aparte de interesante, esta explicación se me queda bastante corta.

Y tú, ¿qué opinas?

La experiencia y el conocimiento suman, pero tu actitud multiplica

Hace poco escuché una frase a un coach que me gustó mucho: la experiencia y el conocimiento suman, pero la actitud multiplica. Fijaros en la fórmula: (E+C)*A. Toda nuestra experiencia que vamos acumulando en cuanto a desarrollo software es vital, así como el conocimiento que vamos adquiriendo a base de la lectura y formación. Sin embargo, todo esto no sirve absolutamente de nada sin una actitud correcta y profesional. Una actitud de esfuerzo y búsqueda de la excelencia. Aún si tenemos poco conocimiento y poca experiencia, nuestra actitud nos llevará a buscar la manera de desarrollar todos esos skills que nos faltan.

actitud

Pero, ¿Qué ocurre si llevamos muchísimos años trabajando sin plantearnos si hay maneras mejores de hacerlo o simplemente sin ser autocríticos con nuestra forma de proceder? Este relato, está orientado a llevarte a la reflexión. Hoy en día, en España, “Scrum está de moda” y muchos adoptan la metodología pensando que es una cuestión principal consistente en leer un libro básico como por ejemplo Scrum y XP desde las trincheras (el cual no dejo de recomendar como iniciación) y seguir el procedimiento sin plantearse realmente de forma crítica si realmente tiene sentido lo que están haciendo, convirtiendo su día a día en rituales y referencias a una documentación que siento decirlo y a muchos les dolerá, pero resume tanto las cosas que puede llevar a la confusión en algunos casos si esta lectura no se complementa con otras (y os dejo aquí algunas sugerencias).

Naturalidad-infancia-Suavinex

A continuación os dejo un relato que escribí hace años. Este relato aunque está lleno de humor negro, no deja de presentar una realidad, al menos en España, que es la falta de profesionalidad. Empresas deciden adoptar una metodología (sea cual fuere, en el caso del relato Scrum, pero como veremos…podría ser cualquier otra) y eligen a personas para liderar el cambio organizacional que no están preparadas. Quizá han acumulado años de experiencia, pero su actitud no es precisamente la adecuada. Normalmente esto se produce por el contexto y falta de motivación. Usaba el nombre de Patrick B. tratando de buscar una relación entre este tipo de persona y la película American psycho. Os dejo con el relato.

american

A Patrick B. le tocó ser Scrum Master: momento y lugar inadecuados él decía sonriendo. En su empresa las cosas iban mal y los proyectos no terminaban del todo bien. Se dieron cuenta de que el 49% de los proyectos terminaban con un sobrecoste, el 27% no terminaban y se cancelaban y el resto estaba al borde de o acabar mal o cancelarse. Aunque había un pequeño número terminaban con éxito, cosa que nunca llegaron a entender. Algunos decían que era por la involucración de cliente en esos proyectos, otros decían que era suerte. A Patrick B. simplemente, no le importaban demasiado estos números.

Chuck Norris - Scrum master

Pero como iba diciendo, Patrick B. era Team Leader. Sumar, quitar y poner horas ya no tenía ningún misterio para él. Con su Gantt en la mano se sentía bastante seguro y “sus chicos”, como él los llamaba, estaban “a tope”. Si eso de la Zona de confort existiera, creo que la de Patrick B. era de látex con doble capa, con un televisor y con un par de pufs para apoyar sus cansadas piernas. Su vida era maravillosa, siempre cumplían los hitos, de una manera u otra. Tenía trucos que nadie conocía, como mandar la entrega en un CD rayado a cliente para tener cinco días más de desarrollo. Infalible.

scrum norris - gantt

Su empresa, una gran multinacional que poseía grandes, pesados y seguros procesos para todo. Tenía en el plan de desarrollo software un modelo en V descrito. La primera vez que escuchó de él, se imaginó que era algo novedoso, pero al parecer llevaba aplicado bastante tiempo. Lo leyó una vez y casi obligado. El caso es que fuera lo que fuera, parece ser que no funcionaba del todo y no tenían claro por qué. Patrick B. sabía que alguien había escrito el documento y lo había subido a control de configuración un tiempo atrás. ¿Qué más había que hacer para que funcionara?

ni idea de lo que hablas

Comenzó la moda en la que las grandes multinacionales con sus pesados, completos y e inexpugnables modelos en V y en cascada querían pasar a eso de las metodologías ágiles. Querían cambiar su filosofía, adaptarse al cambio. En algunas empresas, se contrata a un agile coach o especialista en metodologías de desarrollo. Patrick B. tenía un amigo que se dedicaba a eso y decía que es una gran trampa.  Muchas empresas normalmente no quieren cambiar su forma de trabajar y lo que quieren es que las nuevas formas de trabajar se adapten a ellos dando resultados positivos a corto plazo. Decía que contrataban a un agile coach y pensaban que sin ningún tipo de apoyo por parte de la dirección y mediante extraños rituales conseguirían llevar a cabo esos cambios tan deseados.

dilbert_ideas

Otras empresas contratan a un consultor externo. Pero Patrick B. decía que solían ser gente muy teórica que querían hacer cambios radicales. “Si quisiéramos hacer cambios radicales llamaríamos a Longueras”,  decía Patrick. “Estos devoradores de libros, están media hora y te cobran un ojo de la cara”. Alguien le contestó una vez que no le cobraba los 10 minutos de tiempo por resolver el problema, si no todo el tiempo que había invertido en aprender cómo resolver su problema en 10 minutos.

longueras

El caso es que a Patrick B., le cayó el tema agile y le tocó empaparse de todo esto de los “agiles”. Como Patrick B. era un tipo con recursos, lo primero que hizo fue teclear www.google.com  y buscar “agile V Model” y Eureka! Encontró una página que se titulaba “¿por qué Agile es mejor que V-Model?“. Le pareció curioso que estuviera la séptima y que hubiera antes páginas extrañas que hablaban de manuscritos, comunidades y trincheras. Patrick B. pensó que es lo mismo que cuando buscas cracks que te sale porno por todos sitios.

agile vmodel perturbado

Patrick B. vio un poco los dibujos y sintió que ya sabía de qué iba. Tras un análisis de 30 segundos llegó a la conclusión de que estaba muy bien desde el punto de vista teórico, pero en proyectos de verdad, de los que acaban con sobre-coste o se cancelan, esto no era aplicable… y menos en el suyo. Nunca le llegó a gustar eso del burndown chart: “eso de que la línea vaya hacia abajo y no hacia arriba, le resultaba extrañamente inquietantemente”.

sherlock2

Se  creó un backlog con las cosas que había que hacer, “historias de usuario” las llaman los agilistas. Debían tener una prioridad y un criterio de aceptación. Esto del scrum, es un marco de trabajo así que el bueno de Patrick B. decidió hacer su propia implementación adaptándolo a las necesidades de su proyecto. Decidió que iba a ser product owner y scrum master ya que estos roles se adaptaban más a lo que él conocía de antes. Dicen que son roles que no son compatibles por tener objetivos distintos, pero Patrick B. suponía que esta advertencia era como la fecha de caducidad de los yogures, es decir, opcional.

1241915072NEURAS

Empezaron con las reuniones diarias. Al principio las hacían de pié, pero a partir de los 45 minutos ya les dolía la espalda y decidieron hacerlas sentados. Cada uno contaba lo que había hecho el día anterior y lo que iba a hacer ese día. Dejaron de usar la pizarra porque tener que actualizarla era agotador y la verdad es que nadie la utilizaba. Al poco tiempo tampoco le encontraron mucho sentido a la reunión diaria, salvo para tomar el café de la mañana. Conocieron a mucha gente durante estas dailies ya que la gente se paraba para ver que hacían y algunos acabaron quedándose por hábito. Patrick B. conoció a su mujer en una daily.

batman

Las historias de usuario se mantenían tanto tiempo en la pizarra en progreso que tuvieron que designar responsables de historia de usuario para “ver si eso se movía un poco”. Patrick B. decidió ahondar un poco, mirando el las retrospectivas de los equipos de desarrollo. No solía echarles un vistazo porque opinaba que la gente al final acaba quejándose y no siendo constructiva. Hizo una lista con los últimos sprints pero no obtuvo respuesta ninguna a su problema. Decididamente pensó que la gente se quejaba por vicio. He aquí algunas de sus incoherentes quejas:

  • Los test unitarios tardan 3 horas en ejecutar.
  • Baja cobertura.
  • Rama de desarrollo inestable.
  • Cambios en mitad del sprint.
  • Demasiadas reuniones.
  • Si no nos hacen caso, que no nos pregunten, por favor.

shutterstock_39087388-A

Para favorecer la comunicación, Patrick B. decidió implantar reuniones diarias donde participaran algunos miembros del proyecto de distintos equipos. Eran unos 20 diariamente y trataban temas tan variopintos como el problema que había habido con tal módulo de desarrollo, problemas en testing, en especificaciones o los problemas de Pepe el chico de mantenimiento, que todos los días pasaba por allí hasta que al ver tanta gente reunida decidió tomarse el café de por la mañana con ellos.

tapon-reuters--644x362

Como Patrick B. siempre decía, “esto de las metodologías ágiles es sólo aplicable a entornos de laboratorio. En el mundo real, no funcionan.” No tenían ningún resultado positivo, el número de historias de usuario resueltas no bajaban. La motivación de los equipos estaba por los suelos y la calidad del código estaba deteriorándose cada día más. Patrick B. no paraba de repetir que no funcionaba en entornos reales porque se trataba de metodologías de plastilina.

El jefe de departamento contrató a un consultor Agile muy famoso que les dijo que tenían que partir las historias para reducir el cycle time, los sprints deberían ser del mismo tamaño para poder medir la velocidad del equipo y tenían que volver a hacer retrospectivas, dailies y planificaciones en los sprints. Patrick B. no entendía cómo podía todo eso arreglar su problema. No veía en que podía ayudarles nada de lo que ese famoso agile coach les decía. En las páginas web que había leído sobre agile no ponía absolutamente nada de “cycle time”, o de que los sprints tenían que tener el mismo tamaño. Patrick B. finalmente llegó a la conclusión de que este consultor al que él había admirado durante tanto tiempo se había vuelto tan teórico que ya no tenía los pies en la tierra: en alguna ocasión hasta le había visto intentar levitar.

Coach

En definitiva, Patrick B. se dio cuenta de que nada de esto funcionaba así que decidió volver a la metodología que tenía antes. Un maravilloso modelo en V, que aunque nunca les había dado buenos resultados, estaban acostumbrados a utilizar. Su modelo en V era algo particular y por eso Patrick B. había hecho algunos ajustes:

  • No hacían un análisis previo porque era una pérdida de tiempo ya que los requisitos cambian.
  • Preferían empezar el desarrollo antes de tener los requisitos. Ya que daban prioridad al software corriendo frente a documentación exhaustiva.
  • No creían en los test unitarios. O sólo en aquellas partes importantes…y si hubiera tiempo.
  • En cuanto a la verificación si tenían tiempo lo harían. Pero lo más seguro es que reservaran un mes de la planificación antes de la calificación con cliente para resolver bugs.

american ps

Así, Patrick B. volvió a la oscuridad de la que procedía sin haber aprendido absolutamente nada y con la extraña convicción de que ninguna metodología ágil podía aplicarse a proyectos de verdad y concretamente… al suyo propio.

autocritica

Como vemos en el relato, el problema no es la metodología, simplemente la actitud de las personas. Al final decide volver a lo mismo que tenían antes, pero deciden ajustarlo a su propia comodidad, rompiendo con todos los principios de V-Model, de forma que tampoco están haciendo un modelo en cascada, simplemente están haciendo otro tipo de rituales. Este relato aunque es inventado, las cosas que se cuentan son cosas que en algún momento, en algún equipo y en alguna empresa han ocurrido tal cual. Os invito a reflexionar, si realmente somos parte del ritual, o parte de la solución. La autocrítica, es el primer paso de la excelencia.

https://www.scrum.org/ScrumBut

PDFicono EXTENDIDO