La verdad, hay cosas que por más que las repita, vea y escuche nunca dejaran de sorprenderme de esta nuestra profesión. Una de ellas es la de escuchar un curso, charla o, simplemente, en el acto de “consultorear” cosas como «te vamos a enseñar últimas tecnologías como la agilidad, el ciclo de vida iterativo o… (como es el caso que nos ocupa) TDD».
No hace muchos meses te dejé un post sobre este tema, aquel de Agilidad… ¿Algo novedoso? ¿Estás seguro?, en el que repasaba cómo grandes ideas de la ingeniería software (ya sabes, si te parece un nombre coñazo, puedes ponerle otro de los múltiples nombres que hay por ahí dando vueltas) olvidadas en su tiempo han sido afortunadamente rescatadas, y adaptadas, por el mundo ágil, lo cual es algo genial, lo preocupante es que haya quien nos las quiera vender como novedosas, ya que de muchas de ellas ya se hablaba hace muchos muchos años, antes incluso de que la palabra “agilidad” llegara al mundo software, antes incluso de que yo naciera e incluo seguro que antes de que nacieras tú.
Y el TDD es una de esas prácticas, protagonista del post de hoy.
Quien más ha sido reconocido como padre del TDD ha sido Kent Beck (que supongo no necesita presentación, pero que quizá te suene de los patrones de diseño, por el manifiesto ágil o de eXtreme Programming), si bien Kent Beck siempre dijo que el no había creado el TDD… “lo había redescubierto”, y así sale en varias fuentes, entre ellas la Wikipedia.
De hecho, hasta el propio Kent Beck propició un interesante debate sobre el origen del TDD, lanzando el reto de haber quién era quién podía decir cual fue el primer documento que habló sobre ello.
Si eres de los antiguos de este lugar, quizá recuerdes aquel post de Crónicas sobre la ingeniería del software (1/3) (post del año 2010), en el que, parte de extraerte algunos párrafos curiosos de la primera conferencia sobre ingeniería software, organizada por la OTAN en Alemania en octubre de 1968, te comentaba como muchas definiciones que parecen de “hoy” ya fueron mencionadas en aquella conferencia (conferencia polémica, dicho sea de paso, ya que se considera la iniciadora de la idea de gestionar proyectos software como proyectos “de la construcción, para más detalle aquí te dejo este vídeo), una de ellas es el TDD (sí, sí, año 68), fíate fíjate en este extracto:
A software system can best be designed if the testing is interlaced with the designing instead of being used after the design. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself. […]
Un sistema de software se puede diseñar mejor si la prueba se entrelaza con el diseño en lugar usarse después del diseño. A través de repeticiones sucesivas de este proceso de entrelazar pruebas y modelo todo llega a ser software en sí mismo. […]
Pero es más, como comentan varias fuentes, nuestro venerado Djikstra, ya mencionaba el TDD en el 72, sí, de hecho en el mítico The Humble Programmer (1972) (el programador humilde), al cual le dedicamos un post en 2013, el Lo que le contaría a Dijkstra: cierto, si necesitas un buen desarrollador, ante todo, que sea humilde, Dijkstra decía:
But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. […]
If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.
Pero no deberías hacer primero el programa y luego probar su corrección, porque entonces el requisito de proporcionar la prueba sólo aumentaría la carga de los pobres programador. Por el contrario: el programador debe dejar que la prueba y el programa crezcan de la mano. […]
Si uno primero se pregunta cuál es la estructura de una prueba convincente y después de saberlo entonces construye un programa que satisfaga los requerimientos de esta prueba, entonces estas preocupaciones de corrección resultan ser una guía heurística muy eficaz.
Mmm, TDD mencionado en 1972, en 1968, hace casi 50 años, mmmm ¿nada más? ¿Quieres más? Pues venga…
¿Te acuerdas de cuando te conté que el Veterano ciclo de vida iterativo e incremental (post del año 2010) se usó en los 60? En la NASA en 1960 se empezó a usar para el desarrollo software, en un proyecto llamado Mercury, allí se trabajó con iteraciones diarias, aplicó revisiones técnicas a los cambios, y se aplicó… la técnica de planificar y escribir las pruebas antes de cada micro incremento. Este popular artículo de Larman y Basili cuenta todo ello.
1972, 1968, 1960… ¿Quieres más? Tú mismo.
En aquel interesante debate que te mencioné al principio del post, el que propició Kent Beck sobre el origen del TDD, quien supo dar con el texto más antiguo que hablaba sobre TDD fue Michael Bolton… 1957. En el libro “Digital Computer Programming” D.D. McCracken, año 1957, decía:
In these cases it is highly desirable that the “customer” prepare the check case, largely because logical errors and misunderstandings between the programmer and customer may be pointed out by such procedure. If the customer is to prepare the test solution is best for him to start well in advance of actual checkout, since for any sizable problem it will take several days or weeks to and calculate the test.
En estos casos es muy deseable que el «cliente» prepare el caso de verificación, en gran parte debido a los errores lógicos y malentendidos entre el programador y el cliente pueden ser señalados por dicho procedimiento. Si el cliente prepara la solución a la prueba es mejor para él para iniciar con suficiente antelación la comprobación, ya que para cualquier problema considerable le llevará varios días o semanas.
Lo anterior más que TDD, es el origen del ATDD.
Así que si que si nunca te fíes de un hombre que habla de la «novedosa» TDD
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024