Joan León
Si los test son una parte fundamental en vuestro patrón estructural de desarrollo de software, lo más probable es que quien trabaje en el proyecto siga añadiendo test. Somos expertos en copiar, pegar y modificar. Saquemos partido a esto que sabemos hacer tan bien. - Carlos Blé
Test-Driven Development
Sigo profundizando en aprender e interiorizar las bases del desarrollo de software para poder sentirme cómodo1 cuando afronto un nuevo reto, ya sea en un nuevo proyecto o un proyecto existente. Como desarrolladores/as mejoramos en cada proyecto que participamos, aprendemos nuevas técnicas, nuevas funcionalidades de las nuevas versiones del lenguaje, nuevos patrones. Yo soy la primera persona que me echo las manos a la cabeza cuando recuerdo cómo he programado algunas soluciones en un desarrollo en el pasado.
Cuando empezamos a interesarnos por aprender de las personas más relevantes en el desarrollo de software y en las mejores prácitas, nos encontramos con acrónimos (por cierto, me encanta descifrar el significado de los acrónimos) como SOLID, XP, TDD, BDD o conceptos como Clean Code.
Hoy quiero hablaros de lo que esconde el acrónimo TDD, significa Test-Driven Development. Bueno, no tengo el nivel para poder hablaros de TDD, ya que estoy en proceso de aprendizaje, pero sí quiero hablaros de un libro que me ha ayudado mucho a poder entender las bases o lo que es más importante, conocer las ventajas de desarrollar con esta metodología. Sí, es una metodología, no se trata de una solución para resolver cualquier escenario que nos encontremos.
Diseño Ágil con TDD
El libro que os quiero recomendar es Diseño Ágil con TDD de Carlos Blé. Este es el texto que Carlos ha elegido para definir el libro:
Test-Driven Development es una de las prácticas más relevantes del método XP (eXtreme Programming) desarrollado principalmente por Kent Beck y Ward Cunningham a finales de la década de los 90. Este libro presenta un enfoque moderno, práctico y actualizado de TDD con diferentes lenguajes de programación, apto para cualquier persona que desarrolle software, sea del tipo que sea.
Pero me gustaría compartir qué más he encontrado yo en la lectura.
Disclaimer
Conozco a Carlos en persona, he asistido a algunas de sus charlas, asistió a una de mis charlas y me dió un valioso feedback, le he tenido de profesor en una formación, me ha hecho de guía turístico en Tenerife (gracias Carlos por ese día), he comido con él y hasta he sido testigo de su lucha contra el maltrato animal. Digo todo esto porque creo que conocerle en persona me ha condicionado mucho la lectura, en cada párrafo me parecía escucharle con su voz pausada y tranquila.
Mi opinión
El libro empieza con una definición de qué es Test-Driven Development, y me ha gustado que desde el primer capítulo podemos ver ejemplos de código para famirializarnos con la implementación de TDD.
Soy desarrollador frontend, por lo que cuando veo fragmentos de código en lenguajes como Kodlin me cuesta poder interiorizar los ejemplos, pero la descripción que podemos encontrar ayuda mucho a su comprensión. Y ha sido de gran ayuda ver que en capítulos posteriores hay ejemplos de implementación con JavaScript.
Ha sido una sorpresa, y ejemplo de humildad, leer cómo alguien que es un referente en la comunidad Agile y Crafter hace uso de StackOverflow para buscar una expresión regular que le ayudara a mejorar un test.
El texto está lleno de referencias a libros y personas referentes en la comumidad Crafter, eso y la facilidad de expresar de una manera sencilla conceptos complejos, dejan ver los años de experiencia que tiene Carlos en el tema.
Ayuda mucho que nos explique cómo resuelve problemas, en ocasiones más allá del desarrollo del programa en el que esté trabajando. Leer el siguiente texto me ha abierto la mente al método de cómo afrontar problemas.
A veces escribo test tan sólo para conseguir feedback rápido, a modo de REPL (read-eva-print loop), para resolver dudas que me surgen sobre el lenguaje, la librería, el framework o la integración de varios artefactos del sistema. Tan pronto como disipo las dudas y aprendo sobre el sistema, borro esos test. Es decir, no todos los test que escribo se quedan formando parte de las baterías de test que dan cobertura al código, a veces los uso para obtener feedback y los destruyo cuando lo consigo.
He subrayado muchas frases, incluso párrafos como el anterior, que de algún modo u otro me han marcado. Me ha encantado el capítulo Estilos y Errores, donde recoge varios estilos y nos ayuda a detectar errores comunes y cómo solucionarlos.
Continuar aprendiendo y resolver dudas sobre TDD va más allá de las páginas del libro, ya que nos da la opción de participar en un grupo de soporte, el cual va creciendo poco a poco.
Dar la opinión o recomendar un artículo, libro o charla técnica creo que es igual que recomendar un libro (no técnico), una película o una serie. No a todo el mundo le va a gustar, lo más probable es que muchas de las personas que sigan tu recomendación no lleguen a ver lo que tú has visto. En este caso, a mí este libro me ha ayudado mucho a entender conceptos que estaba aplicando con la práctica del “copy & paste” sin entender bien lo que estaba haciendo. Y es por eso que he querido compartir mi opinión sobre él.
Lo que me ha quedado claro es que para poder tener una opinión sobre cualquier tema, hay que documentarse, ya sea con lectura, vídeos, podcasts, etc… y hay que hacerlo a consciencia, tener la visión de varias personas, nos ayudará a sacar nuestras propias conclusiones.
Así que, ya tengo listo el siguiente libro para seguir buceando en el mundo del testing, Frontend Testing de Iago Lastra.
Referencias
- 1 Quizás algún día esriba sobre estas palabras.