Impresiones de la enseñanza de TDD y otras prácticas

El año pasado comenzamos con la práctica de encuestar informalmente a los alumnos sobre las algunas de las prácticas de desarrollo que estudiamos (y aplicamos) en la materia. Concretamente les consultamos con 3 prácticas que estudiamos en la materia, que consideramos muy beneficiosas pero que curiosamente en la industria no tienen un uso masivo (aún): Mob-programming, Trunk-based development y Desarrollo guiado por Pruebas (BDD/TDD).

Explicamos a los alumnos cómo utilizar estas prácticas y las aplicamos en el contexto de un proyecto de desarrollo.

Si bien los alumnos pueden no utilizar estas prácticas (hecha la ley, hecha la trampa) insistimos en las utilicen principalmente con dos argumentos (ya que en general a los alumnos no les basta con que el docente les diga «es por aquí» ¡ja!):

  • Son prácticas que traen importantes beneficios y cuya efectividad está ampliamente probadas
  • A pesar de lo anterior, son prácticas que en la industria no son mainstream y que incluso se las mira con cierta desconfianza en algunos contextos. En la materia les ofrecemos un ambiente seguro para que puedan experimentar con la práctica, contando incluso con la guía del equipo docente. Si prueban estas prácticas en este contexto ¿donde las van a probar? ¿en sus trabajos con la presión de su jefe, los deadlines y el apuro de la industria?

La actividad de encuesta es bastante simple, les presentamos un cuadro de dos ejes y les pedimos que indiquen ahí cómo fue su experiencia utilizando estas prácticas.

Puede resultar curioso para algunos que la la práctica con mejor evaluación es el desarrollo guiado por pruebas. Cabe destacar aquí que al hablar de desarrollo guiado por pruebas me refiero al uso de BDD/TDD, o sea, guiar el desarrollo a partir de especificaciones en forma de ejemplos (pruebas) generados colaborativamente entre usuarios y el equipo de desarrollo.

Test-Driven Development for Embedded C

Ayer terminé de leer este libro. En una palabra: Excelente.

Lo había tenido en radar por mucho tiempo pero recién ahora con el envión de mi trabajo de investigación sobre TDD decidí invertir tiempo en leerlo. El autor del libro es James Grenning, uno de los 17 autores del Agile Manifesto pero lo que puso el libro en mi radar fue la charla de Grenning «TDD Guided by ZOMBIES» en la cual propone una heurística para definir el orden de la secuencia de tests al hacer TDD.

El hecho de que el título del libro haga referencia a Embedded C es en gran medida anecdótico ya que casi todo el contenido es directamente aplicable a cualquier lenguaje o eventualmente fácilmente extrapolable. Es cierto que algunos capítulos están muy centrados en C y en el desarrollo de software embebido, pero varias de las problemáticas relacionadas a la dependencia del hardware son fácilmente extrapolables a las dependencias de infraestructura que uno se encuentra en el desarrollo de aplicaciones de más alto nivel.

Al margen de TDD, creo que el libro resulta muy valioso para gente trabajando en software embebido ya que provee un conjunto de técnicas que sin duda facilitan/aceleran el desarrollo del software embebido. De hecho lo interesante de las técnicas que propone son aplicables a todo desarrollo a bajo nivel, sea o no embebido. Personalmente he trabajado muy poco con software embebido pero sí he hecho desarrollo en C/C++ y de haber sabido las técnicas mencionadas en este libro creo que habría obtenido mejores resultados.

El libro me ha parecido muy completo, explica los fundamentos de TDD, trata con suficiente detalle las cuestiones de tooling para poder automatizar pruebas en C, escribir código modular y hasta implementar mocking en C. También trata cuestiones de patrones, code smells y trabajo con código legacy.

Para mi es 10 puntos, muy recomendado.

Diseño ágil con TDD

Ayer terminé de leer la edición 2020 de este libro escrito por Carlos Blé. Ya había leído (parcialmente) la edición anterior allá por 2011, pero el año pasado Carlos tuvo la gentileza de regalarme esta nueva versión (¡gracias!) y me comentó que tenía modificaciones importantes así que aproveché que estaba estudiando TDD para mi tesis de maestría y decidí leer el libro de punta a punta.

En una oración: el libro me gustó mucho. Sentí mucha afinidad en la forma de trabajo que relata y también en los consejos que el autor ofrece a título personal.

Encontré un punto de contraste interesante con otros libros de TDD. Creo que la mayoría de los libros que he leído sobre TDD (al igual que la mayoría de charlas, cursos y videos sobre TDD que he visto/presenciado) tienen un tono muy extremo, muy «todo o nada», muy «esto es así» (creo que yo mismo muchas veces peco con ese tono) pero este libro (y creo que Carlos en general) tiene un tono «de mesura», un matiz que me resultó muy ameno y que imagino puede resultar mucho más efectivo a la hora de intentar convencer a alguién de utilizar TDD.

Otra cuestión destacable del libro es no se queda en la explicación de la técnica sino que también trata sobre el uso de la técnica en distintos contextos «reales» de aplicación: en qué tipos de proyectos utilizarla TDD, cómo utilizar TDD en proyectos de código legado, como empezar a utilizar TDD, etc. Trata también la clásica rivalidad de los estilos Chicago vs London de sin necesariamente tomar partido (menciona su preferencia pero no la considera una bala de plata para todo contexto).

Otro punto no menor a destacar es que es uno de los pocos libros (¿acaso el único?) de TDD en castellano.

Creo que es un recurso interesante para aprender TDD, tal vez no entra en tanto detalle como otros libros de TDD pero al mismo cubre muchas más cuestiones, o sea: va más en anchura que en profundidad lo cual me parece bueno para un libro introductorio.

El libro está disponible en formato digital en LeanPub. Muy recomendado.

Highlights sobre el libro «Test-Driven Development By Example»

Esta semana terminé de releer este libro fundacional de TDD. Como ya mencioné no estoy convencido de que sea el punto de entrada más apropiado para aprender TDD, pero sí estoy convencido que todo practicante de TDD debería leerlo.

Personalmente creo que es un libro para leer de punta a punta, sin los capítulos de la tercera parte de libro tratan sobre patrones y se pueden leer en forma descolgada a modo de consulta, los capítulos de las dos primeras partes están dedicados al desarrollo de dos ejemplos en profundidad que luego son referenciamos en los patrones de la tercera parte.

El libro trata ciertas cuestiones de TDD que muchas veces se pasan por alto, algunas veces se las menciona a la pasada y otra vez ni siquiera se mencionan. Algunas de estas cuestiones que me parece vale la pena destacar:

  • El trabajo en forma iterativa y en pequeños pasos es realmente central a TDD. Beck habla de ciclos de 10 minutos (pag. 143).
  • Es completamente válido retroceder para avanzar, si llegamos a un punto donde estamos integrando nuestro código y vemos que hemos roto algo, puede resultar conveniente tirar lo hecho y comenzar de nuevo (pag. 149). Como estamos trabajando en incrementos realmente chicos, lo que vamos a estar tirando no es mucho, es solo el último incremento. Esto lo veo muy relacionado a la técnica Test and Commit or Revert.
  • La técnica «Log String» (pag. 146) es increíblemente simple y útil a la vez que definitivamente le voy a dedicar un artículo exclusivo.
  • Para el programador el código de test es tan importante como el código de dominio. Esto está mencionado de distintas formas a lo largo del libro y como consecuencia de esto no es raro que la cantidad de código de test sea similar a la cantidad de código de dominio. Asimismo el uso de patrones de diseño aplica tanto al código de dominio como al código de test.
  • Si bien el flujo de trabajo es codear un test a la vez, Beck recomienda comenzar la sesión de programación haciendo una lista de los casos que intentaremos cubrir durante la sesión (pag. 126). Esta lista también la utiliza para registrar casos/situaciones que puedan ir surgiendo durante la sesión sin perder el foco de trabajo: estoy trabajando en un caso, surge una idea, la anotamos en la lista y seguimos con los que estábamos (pag. 137)
  • A la hora de escribir los tests puede resultar conveniente comenzar por escribir el Assert (pag. 128)
  • Refactorizar es fundamental, no es posible hacer TDD sin refactorizar y una de las principales razones (o posiblemente la más importante) para refactorizar es evitar la duplicación de código (en realidad más que evitar duplicación de código lo que buscamos es evitar la duplicación de conocimiento). Esto es mencionado en varios lugares a lo largo del libro. Como que Beck está obsesionado con esto.
  • El apéndice 2 del libro desarrolla un ejemplo muy chiquito pero muy clarificador de la esencia de TDD.
  • El orden en que codeamos los tests puede impactar enormemente en el proceso de TDD (pag. 200). Un determinado orden puede hacer que el proceso fluya armónicamente mientras que la misma lista de tests codeada en un orden distinto puede llevar a un callejón sin salida.

Sin duda hay varias cuestiones más para destacar de este libro, pero estas son las que a mi me resonaron.

Comenzando a estudiar TDD

En el contexto de mi investigación sobre TDD decidí a arrancar desde cero a pesar de llevar ya varios años aplicando y enseñando TDD. La técnica Test-Driven Development (TDD) fue «creada» por Kent Beck durante los 90. Y pongo creada entre comillas porque el mismo Beck se define asimismo como «redescubridor» de TDD. Al margen de este acto de humildad, la realidad es que si bien Beck había leído sobre la idea de escribir el código de prueba antes que código funcional, TDD es una técnica que implica mucho más que esa idea.

Sinceramente desconozco cual sea primera mención formal a Test-Driven Development, pero la primera que yo conozco data de la primera edición del libro Extreme Programming Explained escrito por Beck y publicado en 1999. En dicho libro Beck no habla exactamente de Test-Driven Development como técnica sino que simplemente habla de escribir los tests antes de la funcionalidad y hace referencia a esto como estrategia Test-First.

Recién en su libro Test-Driven Development by Example publicado en 2003, Beck entra en los detalles de la técnica TDD. Hace ya años que no recomiendo este libro como puerta de entrada a TDD, porque personalmente me costó mucho hacer el salto de lo que propone el libro «al mundo real». Tengamos presente que los ejemplos del libro (que básicamente son 2 ejemplos tratados con bastante profundidad) están centrados en lo que podríamos denominar la capa de dominio y no lidian con nada de la infraestructura. Esto está muy bien para entender las ideas centrales de la técnica pero resulta insuficiente para poder aplicarla en «contextos industriales». Sin embargo, a partir de mi trabajo de maestría volví a leer el libro y esta relectura me llevó a revalorizarlo. Me resulta interesante cómo algunas cuestiones que descubrí practicando TDD están mencionadas en el libro, pero que en mi primera lectura yo pasé completamente por alto. Más aún, tengo la sensación de que algunas de esas cuestiones son reiteradamente subestimadas por practicantes y «evangelizadores» de TDD. Una de esas cuestiones es la naturaleza iterativa de TDD. Esta naturaleza iterativa, que también es parte central de Agile y DevOps, implica que tenemos que estar dispuestos a avanzar en una dirección con intención exploratoria aún cuando eso pueda implicar volver atrás. Llevado al código esto puede implicar escribir código (funcional o de prueba) sabiendo que en breve lo eliminaremos. Y cuando digo en breve no es dentro de 3 semanas o 3 meses, sino tal vez dentro de 15 minutos.

Son muy pocos los libros que he vuelto a leer de punta a punta. Muchas veces leo un libro de punta a punta cuando lo leo por primera vez y luego vuelvo a leer (generalmente a modo de consulta) algún capítulo en particular. Pero esta vez decidí volver a leer Test-Driven Development by Example de punta a punta otra vez y creo que ha sido una gran inversión pues me ha permitido reflexionar, cuestionarme y entender más profundamente algunas cuestiones.

Mientras escribo estas líneas reflexiono y me convenzo de que si bien yo estoy empezando mi investigación sobre TDD leyendo Test-Driven Development by Example, no es lo que yo recomendaría a un practicante, o sea, a alguien quien aprender TDD para aplicarlo en desarrollo de software. De hecho, la cuestión de por dónde empezar a aprender TDD es una de las cuestiones intento abordar en mi trabajo de investigación.

Tesis de maestría: Enseñanza de TDD

Este año me he propuesto completar mi tesis de maestría. Ya tengo el proyecto planteado y aprobado. La temática del mismo tiene que ver con desarrollar una propuesta para la enseñanza del desarrollo guiado por pruebas. Y si bien en el título de este post menciono TDD, Test-Driven Development, mi planteo es bastante más amplio que el clásico ciclo Red-Green-Refactor, mi idea es centrarme en el desarrollo guiado por pruebas pero desde una perspectiva más «holística» similar la que plantean Freeman y & Pryce en GOOS, viendo el desarrollo guiado por pruebas como un proceso de construcción de software que va más allá del diseño, la codificación y la prueba y que abarca también cuestiones de análisis, requerimientos, deployment y delivery.

La tesis en sí, es la forma de comunicar el trabajo de investigación que uno realiza. Dicho trabajo de investigación puede extenderse por meses o incluso años. Típicamente los trabajos de tesis de maestrías académicas son planteados para ser completados en un año calendario, pero eso no siempre se cumple. En mi caso armé un calendario de trabajo de apróximadamente un un año, pero dado que un año me parece un marco de tiempo demasiado extenso, plantee algunos hitos intermedios representados por publicaciones de las distintas cuestiones que vaya resolviendo.

Más allá de las publicaciones formales que realice, mi idea es ir compartiendo en este espacio algunos de mis avances. En este sentido va este primer post.

Dicho esto, si están interesados en la enseñanza, la prácticas y el aprendizaje de la técnica de desarrollo guiado por pruebas, les recomiendo estén atentos a este espacio.

Continuará…

Percepciones de mis alumnos sobre TDD y otras prácticas de desarrollo

En MeMo2 estudiamos diversas prácticas de desarrollo que luego pedimos a los alumnos utilizar durante el desarrollo de los trabajos grupales. En la clase de ayer, a punto ya de terminar el cuatrimestre, hicimos una muy breve actividad para relevar cómo les resultó el uso de esas prácticas.

Nos centramos en 3 prácticas concretas: Test-Driven Development (outside-in style), Mob-Programming y Trunk-Based Development. Para cada una de estas prácticas les pedimos que se ubiquen en lo que seria un «cuadro cartesiano» donde un eje horizontal representa cuánto utilizaron la práctica y el eje vertical representa el grado de confort/utilidad que sintieron con esa práctica.

En el caso de Mob-Programming las respuestas estuvieron bastante dispersas y sin extremos.

Pero para Trunk-Based Development y Test-Driven Development las respuestas resultaron mucho más categóricas: la gran mayoría indicó haber utilizado mucho lás prácticas con un grado positivo de confort/utilidad.

Personalmente estoy muy contento con estos resultados, que los alumnos perciban utilidad en lo que enseñamos resulta muy reconfortante. La gran duda (habitual en el ámbito académico) es cuanto finalmente terminan «comprando» estas prácticas los alumnos, o sea: fuera del contexto de la materia ¿seguirán utilizando estas prácticas?…..

Notes from my TDD Heuristics Workshop

Yesterday I delivered this workshop at Agile Brazil Conference. It was the second run of this workshop, the first one was last week when I run a «beta» edition that allowed me to adjust several things.

Yesterday’s run was much better, we were able to do more coding and the flow of the workshop was much more clear. Just five people participated of the workshop, which was not surprising for me given that Agile conferences these days are full of people that does not code at all.

Here are the slides I used in the workshop with link to the resources I mentioned. I am very satisfied with the result of the workshop so it is very possible I include it in my software engineering courses.

Taller: Explorando heurísticas para TDD

Este es el taller que estaré facilitando la semana próxima en el contexto de Agile Brazil. Pero dado que es un taller nuevo (nunca antes lo hice) y que en el contexto de la conferencia lo realizaré en inglés, tengo intenciones hacer una corrida previa, a modo de prueba, en castellano y sin co$to, el martes próximo (5/10) a las 19.00 (GMT-3).

Les comparto aquí una breve descripción del taller.

Test-Driven Development es una de las prácticas más populares de Agile pero es al mismo tiempo una de las prácticas más difíciles. Incluso cuando la idea central TDD es fácil de entender, puede resultar verdaderamente duro de aplicar en escenarios no triviales. Entre los factores determinantes para un exitosa y cálida experiencia de TDD está la secuencia de tests que vamos eligiendo para guiar nuestro desarrollo. En este taller con modalidad «hands-on» exploraremos diversas heurísticas para un uso efectivo de TDD.

Personalmente he visto muchos programadores tratando de aplicar TDD y fallando una y otra vez. Yo mismo fallé la primera vez que intenté aplicarlo en un proyecto de industria allá por 2005. Aprendí de esa experiencia fallida, estudié, leí mucho y volví a intentarlo. Hoy en día llevo más de 10 años practicando y enseñando TDD. Estas experiencias y descubrimientos son las compartiré en este taller.

Durante el taller yo trabajaré con Java, Git e Intellij pero los participantes pueden trabajar con el stack de herramientas que gusten.

Los interesados en participar pueden contactarme aquí.

Importante: este taller está dirigido a gente que ya conoce TDD y que tiene experiencia práctica en el uso de TDD.

Los alumnos sobre Mob-Programming y TDD

En MeMo2 @ingenieriauba hacemos un primer TP grupal en el que los alumnos deben evolucionar una webapp existente siguiendo un proceso XP-like (iteraciones semanales, planning, review, retro, CI/CD, DDD, BDD/TDD, etc).

Entre las cosas que más énfasis hacemos y que más les cuesta (o que más resistencia le ponen) los alumnos está el desarrollar guiados por pruebas (bdd/tdd) y trabajar todo el tiempo haciendo Mob-Programming (o al menos pair-programming). También les pedimos que hagan Trunk-Based development.

TDD es algo que ya han visto en alguna materia anterior pero de una forma mucho menos profunda que lo que proponemos en MeMo2. En general los alumnos tiene una buena recepción porque nuestra propuesta de BDD+TDD ofrece una guía muy detallada de como transitar el proceso de construcción desde la intención del usuario hasta el código que implementa esa intención en un ambiente donde el usuario puede utilizar la pieza de software construida.

La propuesta de Mob/Pair-Programming les resulta más «rara», sobre todo a los que ya vienen con experiencia laboral. Posiblemente varios de los que ya trabajan en desarrollo no tendrían el visto bueno de sus jefes si pretendieran trabajar todo el tiempo (o la mayor parte) haciendo Mob/Pair Programming. Por esto es que insistimos tanto en que hagan Mob-Programming, si no lo prueban en nuestra materia, es posible que tampoco lo puedan probar en sus trabajos.

Algo similar ocurre con el uso de Trunk-Based development. Muchos de los que ya trabajan suelen utilizar feature-branches (como creo que hace gran parte de los desarrolladores actualmente) y entonces «temen» trabajar todos simultáneamente sobre el mismo branch. La clave aquí de nuestra propuesta es que al trabajar haciendo mob-programming solo hay un único branch de desarrollo activo, con lo cual resulta natural hacer trunk-based development. Al mismo tiempo y más allá de hacer mob-programming, nosotros insistimos en trabajar en pequeños incrementos haciendo commits al trunk/master cada 20 o 30 minutos como máximo, con lo cual las chances y el tamaño de divergencia al trabajar se reduce mucho, llevando casi a cero el tiempo requerido en arreglar conflictos de merge.

El jueves pasado al finalizar la segunda iteración del trabajo grupal hicimos una actividad con los alumnos para relevar cuanto habían usando las técnicas recomendadas y cuán útiles les habían resultado.

Los siguientes gráficos muestran el resultado de la actividad.

Mi sensación es que la mayoría de los alumnos «compra» nuestra propuesta. Veremos que opinan al finalizar el siguiente TP que reviste una complejidad mucho mayor y donde creo que estas técnicas suman aún más valor.