Cómo aprendí Test Driven Development

TL; TR

Busca a alguien con experiencia en TDD, empieza aprendiendo a escribir buenos test unitario, haz katas para aprender lo básico de TDD y después lánzate a hacer TDD en partes fáciles de implementar de tu aplicación.

Objetivo: como comenzar

El otro día (bueno, no fue el otro día, fue en octubre…) me preguntaron como he aprendido test driven development (TDD) y quería extenderme en la explicación y compartirlo por si a alguien le resulta de utilidad.

Como contexto, decir, que llevo un año practicando TDD y creo que tengo suficientemente fresco los primeros pasos que dí como para escribir este artículo.

Después de leer muchos blogs de como comenzar y de darle a la cabeza, me planteé aprender TDD en dos fases. Primero, aprender como escribir test unitarios (ver mi artículo anterior) y posteriormente TDD.

Lo hice de esta manera porque pensé (y todavía pienso) que TDD está muy vinculado con escribir test de forma correcta y sin una buena base debe de resultar más difícil el aprenderlo.

Primera fase: escribir test unitarios

Así que empecé a escribir test unitarios en casa después de haber aprendido lo básico sobre JUnit, la librería que se suele utilizar como estándar para escribir test unitarios.

Es muy importante que los test que escribas estén bien implementados, ya que solo hay algo peor que un código sin test unitarios, código con test con falso verde. Es decir, que no fallan pero porque no pueden fallar o porque hacen otra cosa diferente que lo que aparece en su nombre.

Después de unos meses escribiendo test me leí el libro Effective Unit Testing de Lasse Koskela y me ayudó radicalmente a mejorar mis test debido a que mientras me lo estaba leyendo recordaba los test que había escrito y como podía haberlo solucionado mejor gracias a los consejos del libro. Me ayudó principalmente en mejorar la legibilidad y la mantenibilidad de mis test.

Luego, empecé en el trabajo a escribir test y me resultó muy pero que muy complicado en muchos casos el escribir test.
Y en un punto me dí cuenta que el problema era que el código que había escrito no era testeable, ya que en un porcentaje muy alto, el código que no tiene test no era testeable. Como comenta Michael Feathers:

Código que no ha sido diseñado para ser testeable no es testeable. La testeabilidad no es cualidad que aparece accidentalmente.

Fue un palo grande pero, después de asumirlo, empecé con la tarea de escribir nuevo código diseñado para ser testeable y poco a poco empecé a hacerlo mejor.

Segunda fase: Test driven development

Al terminar de leer el libro Test driven de Lasse koskela (este tío es un gran escritor), decidí que ya era el momento de empezar con TDD y empecé a hacer katas / code katas.

Según la wikipedia, una kata es un ejercicio que ayuda a los desarrolladores a mejorar sus habilidades como programador.

Puedes encontrar muchos tipos de katas y de muchos niveles en Internet. En cuanto a las herramientas puedes utilizar tu IDE favorito junto con la versión que conozcas de Java y de Junit o puedes utilizar cyber-dojo

Cyber-Dojo es una aplicación web que permite escribir código en tu navegador, compilarlo y ejecutarlo. Además no es solo para Java, sino que permite muchísimos lenguajes como C, C++, C#, Clojure, Grovy y un largo etcétera.

Hice bastantes katas pero no muchas porque me resultaba aburrido el hacerlo solo.

El paso a practicar TDD en el trabajo fue lento. Básicamente, en las nuevas funcionalidades que desarrollaba le dedicaba partes de mi tiempo a practicar TDD. Poco a poco el tiempo a TDD fue creciendo hasta dedicarle todo el tiempo.

Recomendaciones

 

  • Encuentra tu motivación. TDD es difícil de aprender así que tener una motivación te ayudará a seguir. Mi motivación consistía en reducir el número de errores en mi código. Siempre he dedicado un tiempo importante en mi trabajo a solucionar errores y estaba cansado que aunque ponía mucho empeño en solucionarlo de la forma correcta los errores que encontraba y en desarrollar nuevo código sin errores, siempre salían muchos.
  • Busca un mentor o alguien con experiencia en TDD. Te va a ahorrar más de un quebradero de cabeza y mucho tiempo. He aprendido TDD por mi cuenta porque nadie en mi entorno tenía experiencia y con diferencia lo que más eché de menos fue el no haber tenido a nadie a quien poder preguntar. Ahora pensando, a lo mejor hubiera podido haber utilizado Internet para buscar a alguien.
  • Haz cursos que te ayuden en avanzar. En mi caso, hice el curso de Carlos Blé sobre Test dobles y me ayudó a dar el salto a usar dobles de test de forma más activa en mi código.

Nota. Después de leer el artículo varias veces creo que he resumido mucho los pasos que he seguido. Si echas en falta alguna parte, solo tienes que preguntar 🙂