Empezaré diciendo que no he sido nunca un gran practicante de TDD pero sin embargo no critico las pruebas unitarias y si creo que son útiles por multiples razones.

TDD ha calado entre la comunidad poco más o menos como «la solución definitiva» a la calidad del software ganando un montón de adeptos que se han hecho fanáticos de este sistema como es habitual entre la comunidad cuando llega una nueva teoría que gana adeptos muy rapidamente y arrasa haciendo que todo el mundo tenga que aceptarla so pena de parecer un ignorante, aunque hablar de estas olas que más parecen modas que realmente grandes avances sería tema de otro artículo.

TDD surgió como un método para proporcionar una alta calidad a las aplicaciones algo en lo que no pongo dudas ya que todo el desarrollo está centrado en las pruebas, lo cual proporciona el rol dominante a las pruebas por encima de otras consideraciones.

Esto implica varias cosas, TDD impone algunos requisitos de una forma más o menos explícita, por ejemplo cosas obvias como que es necesario tener un buen conocimiento de frameworks de tests unitarios pero tambien otras no tan obvias.

Por ejemplo la refactorización constante, el test siempre va primero esto quiere decir que durante el desarrollo a medida que se implementen nuevos requisitos o cambien algunos habrá que ajustar la aplicación respetando las pruebas unitarias que constituyen la parte principal en este sistema, esto implica continuos cambios en el código para evitar que quede disperso y sin estructura, para mantener la calidad del código a este nivel hace falta tener buenos desarrolladores.

Tambien cualquier sistema de pruebas, no solo TDD, implica tener que hacerlas esto quiere decir una inversión de tiempo, obviamente más pruebas implica más tiempo y cuanto más centrado este el sistema en las pruebas más tiempo conlleva.

Aquí llegamos a un punto clave, la combinación tiempo y recursos, estos dos factores conllevan inevitablemente un aumento del coste y con TDD este coste no es precisamente bajo, necesitas buenos desarrolladores y tiempo para hacer la aplicación.

Habrá quien diga que este sistema no excluye programadores junior que pueden estar realizando otras tareas de bajo nivel y que en el futuro aprenderán un buen sistema de desarrollo, habrá también quien diga que el producto de calidad implica tiempo y no se pueden pedir las cosas «de un día para otro», incluso dirán que un equipo disciplinado en TDD no implica una variación sustancial en tiempo.

La realidad no es esa, no todos los clientes van a aceptar algo así y no todas las empresas pueden permitirse ofertar ese tipo de desarrollos, independientemente de que se vendan como productos de alta calidad.

Tampoco pretendo quitar valor a TDD, simplemente que no sirve para todos los desarrollos, en mi opinión tiene cabida en sectores críticos, por ejemplo: defensa, sanidad, … donde la calidad ha de ser máxima y los errores implican grandes pérdidas ya sean materiales o humanas.

A fin de cuentas la conclusión es, si para que TDD funcione necesitas, aparte de una gran comprensión por parte del cliente,  tiempo y recursos, ¿cómo de malo tendría que ser para que aún asi no funcionase?