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.

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.

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.