Otro gran debate sobre TDD comenzó en Twitter y en la blogosfera. ¿Está muerto el TDD? (No, eso es ridículo.) ¿Mejora o perjudica nuestro diseño? ¿Nos hace más rápidos o más lentos? Seb Rose recopiló una lista de blogs y tweets al respecto, así que no los repetiré aquí. Si no estás al tanto de todo el debate, lee todos los enlaces que Seb recopiló al final de su post.
Llevo muchos años utilizando TDD y, aunque estoy plenamente convencido de sus ventajas, no voy a describir los pros y los contras de TDD desde mi propio punto de vista. Eso sería un poco egoísta. Lo que espero hacer aquí es plantear algunos puntos que no se han planteado antes en las discusiones que he visto.
"Soy genial, tú no"
Hay una buena parte de desarrolladores que piensan así. Todo gira en torno a ellos. Son personas que prefieren trabajar por su cuenta antes que en equipo. Suelen sentirse más cómodos recibiendo algunos requisitos y resolviendo esos problemas por su cuenta en un lugar donde no se les desafíe. Codificarán por su cuenta hasta que sientan que han terminado. No necesitan hacer pairing, ni escribir pruebas. Prefieren no aprender nuevas herramientas y prácticas porque ya se consideran profesionales increíbles. O eso creen.
Los desarrolladores que encajan en esta descripción son normalmente los que se resisten más al TDD, por no decir que están totalmente en contra. TDD les frena y daña su idea preconcebida de buen diseño. TDD no les ayuda porque conocen bien su base de código y pueden encontrar errores con bastante rapidez. Como son los únicos que trabajan en el código base, muy raramente cometen un error. Saben dónde cambiar y cómo hacerlo.
¿Estoy siendo injusto? ¿Cómo sé que algunos desarrolladores piensan así? La respuesta es sencilla: yo fui uno de ellos. Así es exactamente como pensaba hace algunos años.
"Este código es un desastre. ¿Quién ha escrito esto?". ¿Cuántas veces hemos dicho (o al menos pensado) eso? Pues aquí tienes una noticia: si alguna vez has trabajado en equipo, ten por seguro que han pensado lo mismo de ti y de tu código. Sí, duele. Así que ahora ya sabes cómo se sienten otros developers.
Otra noticia para ti: si siempre trabajas solo, o prefieres trabajar solo, lo más probable es que no seas tan bueno como crees. Otros desarrolladores son quienes mejor pueden juzgar tu destreza, no tú.
Si no sueles trabajar en equipo, o no tienes a otras personas trabajando constantemente en la misma base de código que tú, lo siento, pero probablemente tengas una opinión muy sesgada y no contrastada, especialmente en lo que se refiere a TDD y otras prácticas de programación.
TDD no es sobre ti...
Durante la mayor parte de mi carrera he trabajado en equipo. En los últimos años he trabajado en grandes proyectos con muchos equipos en distintas partes del mundo. En un equipo no hay un "yo". En un equipo no existe el "yo no hago esto".
Un equipo sano es aquel en el que los miembros se respetan mutuamente y producen un código que cumple las normas establecidas por el equipo.
Los proyectos de software, al menos a los que estoy acostumbrado -no prototipos, pequeñas aplicaciones web CRUD o móviles- trascienden a las personas. Los proyectos siguen evolucionando y manteniéndose a medida que los desarrolladores van y vienen. Un gran desarrollador entiende eso. Entiende que otras personas necesitarán mantener su código, mucho después de que él se haya ido. Sabe que cada profesional tiene una idea diferente de lo que significa un buen código. Entiende que el software progresa y necesita cambiar. Y, sobre todo, entiende lo difícil que es trabajar con una gran base de código de la que sabe muy poco.
Ahora, recuerda aquel proyecto al que te uniste hace algún tiempo. Aquel en el que el código estaba supuestamente escrito por gente inteligente, pero por desgracia todos se han ido. O ese otro proyecto, que era un desastre total y nadie sabía lo que estaba pasando. O incluso ese con una enorme base de código, donde los requisitos cambiaban a diario. "Ah, si al menos tuviéramos algunos tests". Tests en los que pudiéramos confiar y nos dijeran la intención del código. Tests que nos dieran seguridad para cambiar esa base de código complicada y desconocida. Tests que harían nuestra experiencia de trabajo en ese código base bastante agradable, y no nuestro mayor dolor.
¿No sería agradable si pudiéramos pulsar un botón, y en unos minutos, si no segundos, pudiéramos tener la confianza de que no hemos roto nada? Ah, si al menos esos otros desarrolladores hubieran escrito algunas pruebas. Pruebas que me dijeran qué se supone que debe hacer este código. Ahora tenemos que lidiar con este lío sin tener ni idea de si vamos a romper algo. "Si al menos el código estuviera desacoplado de los frameworks, podría intentar escribir algunas pruebas rápidamente y dar sentido a todo este lío".
No seas el desarrollador egocéntrico
Yo he sido el desarrollador egocéntrico en el pasado. Hice cosas que potencialmente causaron dolor a otros compañeros. Hoy, independientemente de lo que piense sobre mis propias habilidades, sé que un proyecto de software no es sobre mí. Un proyecto de software no depende de una sola persona. Así que si sigues pensando que no necesitas TDD o pruebas automatizadas, piensa en todos los demás desarrolladores que mantendrán ese código cuando tú ya no estés. Sobre todo, piensa en ti mismo uniéndote a otro proyecto sin tests, posiblemente escrito por desarrolladores que se creen tan geniales como tú.
Si todavía no quieres hacer TDD, bien. No pasa nada. Mi pregunta es: ¿Qué vas a hacer en su lugar que dará a otros desarrolladores la confianza para trabajar en el código que has producido? Lo siento, pero tu asombrosa noción de diseño no es lo suficientemente buena si no está validada y acordada por el resto del equipo (y todos los futuros desarrolladores que alguna vez trabajarán en esa base de código).
