Desde hace dos semanas ha causado cierto revuelo en las comunidades de desarrollo este articulo de David Heinemeier Hansson, creador de Ruby on Rails, donde básicamente apunta que él seguirá usando Unit Test pero que TDD (entendido como programar los tests antes de codificar) ya esta muerto y que no tiene beneficios, de ahi me quedo con esta porción:

The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first).
I don’t think that’s healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that’s «slow». Like hitting the database. Or file IO. Or going through the browser to test the whole system. It’s given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

Y si, se podría decir que había mucho de fanatismo en esto, expresiones como «código legado es código sin tests», «WebForms es malo pues pues no deja testear», «elabora una arquitectura evolutiva basada en tus tests» y similares estaban a la orden del día en blogs y conferencias, de hecho cuando publique este post sobre si los nuevos patrones (inducidos por TDD) ayudaban o no a la legibilidad del código un guru dijo que yo había «missed the point».

No se me entienda mal, yo creo que los tests son necesarios y salvadores de tiempo… en algunas circunstancias, por ejemplo hace un tiempo vi a un QA probar una aplicación que calculaba ciertos valores, para hacer esto iba a su Excel, copiaba los parámetros en la aplicación, y si la aplicación devolvía el valor esperado que estaba anotado en el Excel, estaba Ok, y claro, como es usual si la aplicación era actualizada, estos tests deberían ejecutarse de nuevo para verificar que no hubiera una regresión, este es un caso muy evidente como batería de Unit Test con diversas combinaciones de valores ayudaría a reducir los tiempos de prueba, garantizando la calidad de la aplicación en cuestión, como siempre digo, ¡si en una aplicación de cálculos matemáticos o financieros no le metes Unit Test no te puedes fiar de la calidad para nada!.

Personalmente creo que en este caso opero mucho el «principio de autoridad», eran pocas las voces quienes cuestionaban de que el modelo de TDD (y la compleja arquitectura a la que podria derivar) sea totalmente valido, y era necesario que alguien con cierto peso dijera «el emperador esta desnudo».

Como era de esperar, algunas respetadas voces han respondido al manifiesto de DHH, destacando Robert Martin con este articulo, y luego un debate online entre DHH, muy interesante.

Creo que el debate continuara un buen rato, pero lo bueno es que ha permitido que quienes teníamos reparos al fundamentalismo del TDD podamos salir de nuestros agujeros sin ser abucheados.