Recientemente hablaba con un cliente sobre TDD y su poco uso en la industria a pesar de sus probados beneficios. Durante la charla me encontré, sin haberlo meditado previamente, hablando sobre confusiones habituales respecto de TDD que a mi parecer le juegan en contra.

La primer confusión, y posiblemente la más común, es confundir TDD con una técnica de testing. TDD no es una técnica de testing, como su nombre lo indica es un técnica de desarrollo. Al creer que es una técnica de testing, hay desarrolladores que directamente la dejan de lado (sin siquiera probarla) pensando que no es para uso de los desarrolladores sino para el uso de los testers :-(. Algo que aporta a esta confusión es que en algunas instituciones TDD es estudiado en materias de testing/calidad en lugar de materias de diseño/desarrollo. A favor de los confundidos admito que el nombre (Test-Driven Development) a pesar de ser preciso, puede resultar confuso.

Otra confusión que he visto reiteradamente en quienes comienzan/intentan utilizar TDD es ir directo al código sin absolutamente ningún ejercicio de diseño preliminar . La técnica es muy explícita en cuanto a comenzar por los tests y trabajar en pequeños incrementos. Pero ello no significa que no pueda (¿o deba?) hacer un poco de diseño preliminar, haciendo incluso algún diagrama y pensando en el diseño «final» (o diseño a mediano/largo plazo). En una época (allá por los ’90) había gente que hacía diseños muy detallados y luego pasaba de una a intentar implementar esos diseños en código. Luego de esa experiencia poco feliz, algunos se fueron al otro extremo sin siquiera pensar un poco antes de saltar al código. En lo personal siempre me gusta comenzar haciendo un diagrama del dominio del problema antes de saltar al código. Al mismo tiempo, cuando salto al código no es para implementar de una el dominio completo, sino que la implementación del dominio la hago incrementalmente generando incluso versiones reducidas/incompletas pero entregables al usuario. De esta forma puedo llegar a generar varias versiones de cara al usuario antes de tener materializar la visión inicial del dominio (que por cierto, es una visión que va evolucionando a medida que voy aprendiendo más del dominio).

Omitir premisas de la técnica es también una error habitual. TDD no es solamente comenzar por la prueba, hay varias cuestiones más y entre ellas una fundamental es trabajar en pequeños incrementos. Al no trabajar en pequeños incrementos, las pruebas que escribimos pueden ser más grandes/complejas y requerir mayor esfuerzo para hacerlas pasar. Al mismo tiempo podemos estar complicando el diseño (y la implementación) innecesariamente.

Finalmente, algunos creen que al hacer TDD no es necesario un esfuerzo de testing posterior y entonces no es necesario contar con la colaboración de testers en el proceso de desarrollo. Dado que TDD no es una técnica de testing, necesitamos testear nuestro software más allá de que hallamos hecho TDD. Obviamente que las características de ese testing van a ser distintas dependiendo de si el software fue desarrollado haciendo TDD o no. De entrada, si hicimos TDD el esfuerzo de testing posterior va a ser mucho menor pues varios casos ya van a estar testeados. También debemos tener presente que los tests generados en el ciclo de TDD son distintos a los tests que un tester realiza a posteriori, esto es así porque el objetivo de unos y otros tests es distinto. Más aún, TDD es una técnica surgida en un contexto Agile donde el rol de tester es radicalmente distinto a rol del tester en un contexto «tradicional» (no Agile) pero esto es material de otro artículo.

Practico TDD, enseño TDD e investigo sobre TDD. Hoy 2023 TDD es bastante conocido pero bastante menos practicado. Yo tengo mis propias sospechas pero recientemente me he encontrado con dos posibles explicaciones adicionales. En este sentido quiero referirme aquí al trabajo de Ghafari y colegas.

Comienzo explicando el contexto: si buscamos estudios sobre los beneficios de TDD vamos a encontrar evidencia no concluyente, o sea: encontraremos algunos estudios que a partir de experimentos aseveran ciertos beneficios de TDD al mismo tiempo que otros estudios hablan de limitaciones o incluso que la técnica no goza de ciertos beneficios. Ejemplo: algunos estudios indican que TDD mejora la calidad del código pero al mismo tiempo empeora la productividad. Otros estudios dicen que TDD no tiene impacto en la calidad e incluso algún otro habla de que tampoco impacta en la productividad.

A partir de esto, Ghafari y compañía, en su trabajo «Why Research on Test-Driven Development is Inconclusive?«, se propusieron estudiar la razón de estos resultados inconclusos. Para esto analizaron diversos estudios existentes sobre TDD y básicamente identificaron 5 factores:

1. Definición de TDD: según indican, en los distintos estudios que analizaron se utilizan diferentes definiciones de TDD. Esto en lo personal me resultó muy raro, al menos en el sentido que los autores lo indican. Al margen de lo que indican los autores, lo que personalmente me resuena es que en mi propio trabajo de investigación he notado diferentes concepciones de TDD. Hay gente que entiende por TDD puntualmente lo descripto por Beck en su libro Test-Driven Development by Example, lo cual se centra en aplicar TDD a nivel «diseño de clases», muy asociado a prueba «chica» (onda unitaria), mientras que otros toman TDD como una idea más amplia, aplicable a distintos niveles de abstracción como son BDD/ATDD/SBE y más en línea con lo que el propio Beck menciona en su entrevista a Software Engineering Radio.
2. Selección de los participantes: muchos de los estudios se hacen con estudiantes o con gente de industria que ha recibido una breve capacitación en TDD. Ambas situaciones son al menos discutibles para poder sacar métricas concluyentes. Si queremos llegar al fondo del asunto debemos realizar estudios con gente experimentada en el uso de TDD.
3. Selección de la tarea: en general los experimentos utilizan ejercicios/tareas que distan mucho en complejidad de lo que uno se encuentra en «escenarios reales»
4. Tipo de proyecto: la mayoría de los estudios se enfoca en «proyectos nuevos» (green field) cuando en los contextos reales es habitual tener que lidiar con proyectos existentes (brown field)
5. Comparación: TDD es una práctica de uso en contextos ágiles, con lo cual al hacer estudios comparativos debería comparar el uso de TDD vs. (No-TDD en un contexto ágil), cosa que no siempre es así. Hay estudios en los que se compara el «uso de TDD» vs. «No-TDD en contextos waterfall», los resultados de este tipo de comparación puede deberse tanto al No uso TDD como también al uso de Waterfall. Es fundamental al comparar tener presente el contexto. También resulta relevante considerar distintos escenarios de No-TDD: Test-Last, Iterative Test-Last, No-Test-at-All pues la implicancias de la comparación pueden resultar muy distintas.

En términos generales me parecen bastante razonables estos 5 factores y obviamente los tendré presentes en mi propios trabajos. Para quienes quieran profundizar en esta cuestión les recomiendo leer el artículo completo, es bastante corto y de lectura llevadera.