No he encontrado evidencia ahí fuera de que el TDD mejore ni la productividad ni la calidad del desarrollo de software. De hecho creo que no se puede conseguir porque el desarrollo de software es algo tan complejo que no tenemos la capacidad para realizar experimentos fiables.

Sobre la falta de evidencia

Cuando hablo de evidencia me estoy refiriendo a la existencia de datos que avalen o refuten dicha hipótesis.

El problema, en mi opinión, radica en la cantidad de variables no controlables que influyen en la productividad y en las características que hacen de cada proyecto de desarrollo de software algo único.

De lo poco que he encontrado ha sido algún estudio como éste, del que se puede sacar poca conclusión, tal y como dicen los propios autores.

Dicho esto, y citando a Carl Sagan, la ausencia de evidencia no es evidencia de ausencia.

Ante la falta de evidencia…

Así que, ¿qué hacemos ante la falta de evidencia? Pues creo que lo primero de todo es asumirlo y aceptar que, a partir de aquí, nos movemos en el ámbito de las opiniones y las experiencias personales.

Yo tengo mi opinión y tengo mi criterio. Ambos, por supuesto, con todo mi sesgo. Y como siempre, mi opinión ha ido cambiando a lo largo de todo el espectro posible:

He pensado que los tests no servían para nada

He pensado que cualquier problema se solucionaba con tests

He pensado que el TDD era absurdo

He pensado que el TDD está mal enfocado

He pensado que todos deberíamos hacer TDD

He pensado que en el fondo daba igual la calidad del código

He pensado que la calidad del código era fundamental

…y más

Así que mi opinión hoy es que:

No hay causalidad, sino correlación

Hacer TDD no mejora la calidad del software en sí mismo. Lo que mejora la calidad del software es saber hacer TDD.

Hacer testing es, en mi opinión, lo más complicado del desarrollo. Requiere muchísima capacidad de abstracción, necesitas conocer principios de programación como SOLID que están muy lejos de ser triviales, y necesitas un conocimiento alto de las herramientas para poder realizar el trabajo de forma eficiente.

Es, por lo tanto, la experiencia del equipo y no la práctica en sí lo que hay que perseguir… lo que pasa es que saber hacer buen TDD es un signo de experiencia del equipo.

Lo importante es el diseño, no la implementación

Creo que la última D de TDD no debería ser Development, sino Design. En mi opinión el mayor valor de hacer TDD no son los tests en sí mismos, sino el diseño que surge de ahí. Puedes tener calidad con un buen diseño sin tests, pero no tienes calidad con un mal diseño por muchos tests que tengas.

El TDD me ayuda a diseñar y, de paso como subproducto, me genera unos tests que me facilitan la vida y dotan al proyecto de cierta robustez.

No son pocos los proyectos que he visto en los que se hacía TDD de libro™, pero su resultado ha sido contraproducente por no haber aplicado bien principios de diseño. Eso sí, estaban forrados de tests.

La calidad cuesta dinero y el nivel de calidad sí es negociable

La calidad cuesta dinero. Y uno puede decidir el nivel de calidad que ofrece… y compra.

La calidad es negociable cuando compras un coche, cuando te bebes un vino o cuando amueblas un salón. Y por supuesto, la calidad es negociable cuando construyes software.

Y no. Estas decisiones no se toman con el “gorro” de ingeniero puesto. Estas decisiones se toman con el “gorro” de negocio. ¿Quién es tu cliente? ¿Para qué necesita su producto? ¿En qué fase de desarrollo está? ¿Es un prototipo que le sirve para validar una idea de negocio? ¿Es una aplicación con una base de usuarios enorme? ¿Pertenece a un negocio regulado? ¿A qué sector de mercado va dirigido y cómo de copado está?

Hacer o no hacer TDD, o testing en general, o cualquier otra decisión que creamos que influye en la calidad no depende de que nosotros, los desarrolladores, nos sintamos más o menos seguros de desplegar a producción. Depende del impacto que se genera a nivel de negocio.

El mayor valor de hacer TDD lo recibo yo, no el producto.

Creo que el mayor beneficiado de hacer TDD es el propio desarrollador, no el producto en sí. Tras practicar TDD en los proyectos en los que he estado, mi conclusión es que el gran beneficiado de haber hecho TDD he sido yo.

Haciendo TDD he aprendido a diseñar mejor y he interiorizado mucho mejor principios como SOLID, YAGNI o DRY, me he obligado a hacer reflexiones que normalmente no me permitía hacer sobre “qué estoy construyendo”, “por qué lo estoy construyendo” y “para qué lo estoy construyendo”.

Siento que todo esto me ha hecho crecer a nivel intelectual. Soy capaz de manejar mayor número de abstracciones y de “elevar” el proceso de razonamiento lógico.

Mi consejo a todo desarrollador es que invierta tiempo en practicar TDD. Ya sea en el proyecto en el que esté trabajando o en un propio.

Mi postura sobre si hacer TDD o no

Pues, como todo, dependiendo del contexto. Algunos ejemplos de trazo grueso:

  • Si hablamos de un pet project que hago por hobby, sin duda.
  • Si estamos en una fase de prototipado y de exploración, no.
  • Si hablamos de un MPV cuyo objetivo es validar una idea de negocio, no, salvo en partes críticas del mismo como pagos, seguridad o requisitos regulatorios.
  • Si hablamos de un proyecto en marcha, validado y de un tamaño razonable, casi con toda probabilidad que sí…

Las opiniones son como los culos…

…todo el mundo tiene una y no nos gusta como huelen las del resto.

Así que si no te gusta lo que opino o no estás de acuerdo, pues da un poco igual. No busco convencer a nadie, sino compartir mis reflexiones basadas en mi experiencia. A mí me ha ayudado mucho conocer opiniones sobre este tema. Unas me han gustado más y otras menos, pero al final todas me han ayudado a formar mi propio criterio. Y ésta es mi forma de poner mi granito de arena en lo que me gustaría que fuera un debate constructivo, basado en la duda y alejado de fundamentalismos de cualquier tipo.

Mientras no encuentre evidencias que validen o refuten las bondades del TDD, yo voy a seguir afinando mi postura con respecto a este tema, pero no dejará de ser una opinión. Más o menos válida para según quién, pero una opinión al fin y al cabo.

Y si alguien encuentra evidencias ahí fuera… pues que las comparta :-)

De hecho hay dos cosas, ciencia y opinión; la primera responde al conocimiento, la segunda a la ignorancia.
Hipócrates