Mi particular visión del Test Driven Development (TDD)

Cuando nos enfrentamos al diseño de un programa sea el que sea, partimos de un estado que podemos llamar “A” problema, y como es obvio un estado “B” en el que tenemos resuelto el problema, por medio de un programa.

Si la programación fuera como las matemáticas, cosa que “no es” aunque  se fundamente en ello; la solución ideal sería la línea recta. Una línea recta que nos lleva del punto “A” al punto “B”, directamente, sin rodeos.

Es la solución más ELEGANTE, por qué es la solución más CLARA y BREVE que se puede dar.

Hay partes de la programación en donde existen uno o varios algoritmos que podemos usar y que son como la línea recta es decir ya están optimizados y no hay manera de mejorar (algoritmos de ordenación, búsqueda, etc..) pero cuando hablamos de un sistema de mayor tamaño, donde se ven involucrados más componentes la cosa cambia.

Existen miles de maneras de llegar de “A” a “B”, podemos hacer tirabuzones, hipérbolas, curvas mágicas y un sinfín de figuras geométricas que nos llevarán también de “A” a “B”. Los programadores somos capaces de crear miles y miles de esas formas mágicas. (Es nuestra naturaleza, como le dijo el escorpión a la rana)

De modo que nos enfrentamos a un problema doble, llegar del punto “A”, problema, al punto “B”, programa  sin morir en el intento. Y hacerlo de la manera más ELEGANTE.

No hace mucho, hablaba Rodrigo, del “Principio KISS” y del “Divide y Vencerás”, este último es sin duda la práctica que seguimos todos los programadores desde que tenemos conocimiento de nosotros mismos, es decir de que somos eso “Programadores”.
 
Debemos resolver un problema, es decir crear un programa “B”, que resuelva “A”, y hay miles de soluciones ó caminos posibles que nos llevarán de “A” a “B”.

Nosotros no disponemos de un algoritmo determinado, de una solución magistral como la ecuación de la recta que pasa por dos puntos, cada programador es un mundo y su percepción tanto del problema como del modo de llegar a la solución (diseño) podemos decir que es casi única, cuya aproximación es inversamente proporcional a la complejidad del problema.

A un problema más sencillo, hay más posibilidades de que dos programadores sigan el mismo camino, a un problema más complejo la desviación entre las soluciones tiende a distar más.

No existe la certeza de que nuestra solución sea la más optima, clara y concisa y lo que es peor tampoco podemos medir desviación alguna, puesto que cuanto más complejo es el programa más variantes tiene y por ende para poder medir dicha desviación, deberíamos conocer la línea recta, cosa que a priori es imposible.

Partiendo como base de que la línea recta sería la solución “perfecta” del problema, tenemos una complicada tarea.

Pero por otro lado una línea no es más que una sucesión de puntos, de modo, que podemos interpretar cada punto como una parte de la solución, y aquí volvemos al “Divide y Vencerás”.

Gracias a que tenemos técnicas como el TDD o ATDD, podemos ir punto por punto trazando nuestra línea.

“Solo escribimos el código necesario para pasar la prueba”, esta frase que resume en esencia que es “Test Driven Development”, también es la mejor manera que conozco de ir punto por punto trazando la solución de “A” a “B”, siguiendo esa imaginaría línea recta que sería la solución más ELEGANTE, CLARA y BREVE que se puede dar.

11 comentarios en “Mi particular visión del Test Driven Development (TDD)”

  1. La verdad que es dificil decir tan poco en tantas palabras.
    Sin acritud, en tu blog pones lo que te da la gana, pero con responsabilidad debes pensar que habra gente que entrara a ver el contenido seducida por el titulo del post.Y este post no le vale a nadie!! estas haciendo perder el tiempo a un monton de gente, deberian meterte en la carcel.

  2. @Pedro – Bueno, como he dicho es “Mi Particular Visión”, es una OPINIÓN. Nadie te obliga a leer el post, o a dejar de leerlo a la mitad, por lo menos veo que lo has leído y has opinado;

    Eso de que “no le vale a nadie”, deberías dejar que el resto lo judge ¿no?, una vez más, a ti no te ha valido, vale, estoy totalmente de acuerdo, pero tal vez a alguien SI le interese lo que pienso…

    Por último, lo de deberían meterte en la cárcel, creo que esta fuera de lugar.

  3. Ufff… Pedro, entiendo que no has debido entender la importancia de lo que Carlos plantea, pues solo así puedo entender tu comentario.

    El mensaje de Carlos, tal y como yo lo entiendo es claro y de suma importancia, resumiendo a ver si así te enteras: Programar es un camino exploratorio en busca de una solución, este camino debe ser el más simple posible y es dificil de encontrar sin iterear. Usar TDD nos permite iterar en busca del mejor camino, del más simple, de forma cómoda, productiva y segura.

    Carlos, no puedo estar mas de acuerdo con tu mensaje. Y creo que hay que repetirlo a menudo para que más y más desarrolladores se enteren.

    ¡Saludos a todos!

  4. Siento no estar deacuerdo con alguna de estas afirmaciones, si bien se recomienda comenzar realizar la prueba antes del código, la prueba solo te garantiza que el programa hace aquello para lo que ha sido diseñado.

    La utilización de TDD, no garantiza que el camino escogido para resolver un problema sea el mas simple, aunque cambie la forma en la que desarrollamos habitualmente. Si bien evitara cometer algunos errores a la hora de diseñar un programa y consecuentemente hara que seamos mas productivos en la detección errores.

  5. @Juan, Usar TDD no significa dejar de pensar, ó de hacer un pre-diseño de la solución; Puede que este punto no lo haya explicado, pero para hacer TDD hay que pensar y mucho, solo el elegir por qué prueba empezar puede suponer tremendo esfuerzo, sobre todo cuando se comienza.

    Dices que TDD no garantiza que el diseño sea el más simple posible, hombre piensa que esa garantía es responsabilidad del que escribe las pruebas, ir pasito a pasito de poquito en poquito, es muy difícil, a mi me ha costado una barbaridad; Piensa que las pruebas es como construir una casa, si la primera prueba que escribes es para el tejado, pues como es lógico el código que debes escribir es la casa completa.

    Cuando haces TDD, estás haciendo muchas cosas, estas diseñando (modelado ágil), vas pasito a pasito (cimentando), estas fijando la sintaxis y cómo quieres que el programa se exprese, rafactorizas, eliminas duplicaciones, garantizas que tu código sea testable desde el principio y no solo las clases, sino que conforme va creciendo, vas probando no las clases si no los casos de uso y las historias de usuario que en definitiva son los requisitos que debemos cumplir.

    “la prueba solo te garantiza que el programa hace aquello para lo que ha sido diseñado”, vaya aunque solo sea esto, ¿te parece poco?

    Como programadores debemos asumir (aunque cueste) que la solución más simple es la mejor solución.

    Por último, permíteme una pregunta ¿has intentado ó has hecho TDD?.

  6. @Carlos, no te equivoques, no estoy discutiendo las ventajas de TDD, llevo ya casi tres años utilizando TDD, si no, no lo haría.

    Aunque reconozco que son pocas las veces que comienzo con la prueba unitaria antes de la implementación del programa, este puede ser un factor diferenciador importante, en cualquier caso antes de la prueba y del propio programa nos basamos en la arquitectura y el análisis del proceso, estos se tratan y discuten con el equipo de desarrollo, donde se establece la solución más adecuada para abordar el problema. Es aquí donde se observa por primera vez la complejidad de un determinado proceso y donde debemos buscar conjuntamente con el equipo de desarrollo la solución más adecuada, antes de iniciar si quiera la prueba y el programa. No coincido en que TDD te proporcione desarrollar modelos sencillos, si bien estoy de acuerdo en que puede hacer que tu código sea mucho mas optimo, evites errores al escribirlo y localices errores antes de ponerlo en producción, pero puedo tener 10000 pruebas unitarias en mis desarrollos, con una cobertura del 90%, eliminar todos los duplicados, cumplir con todas las reglas de estilo y de calidad y tener un sistema sumamente complejo que podría ser infinitamente más sencillo.

  7. @unai – Lo intentaré. Poquito a poco dependiendo de mi Health Status.

    @Juan – Creo que son distintos planteamientos, por un lado creo que estás más cerca de la ingeniería de software pura y dura que de las metodologías agiles, corrígeme si me equivoco.

    Yo lo que defiendo, y como el titulo del post dice, es una visión particular, con lo cual entiendo perfectamente que se esté en desacuerdo con lo que digo. Y por otro lado me encanta que los comentarios aunque estén en desacuerdo sean constructivos.

    Tener un sistema complejo, es normal, hacemos programas complejos, pero se trata de hacer implementaciones sencillas para resolver esos problemas. Y es el TDD, el camino que yo encuentro más acertado.

    Dices que puedes tener un sistema complejo que podría ser infinitamente, más sencillo, ¿pero como sabes que puede ser más sencillo? Y ¿Si sabes que puede ser más sencillo, como es que llegas a una implementación compleja?

  8. @Carlos, no sé porque crees esto, si utilizar Scrum, Testeo Unitario, Programación en parejas, Refactoring, etc, etc, lo denominas estar más cerca de la ingeniería de software pura y dura entonces sí.

    Tan solo no comparto la afirmación que expones en la que TDD, te hace realizar los desarrollos de forma más simple, en nuestro caso tratamos la complejidad de una solución cuando se analizan las historias de usuario y como utilizamos Scrum en la planificación del sprint y en las reuniones diarias, antes de realizar la implementación, entre todos se expone el problema y se busca la solución más adecuada, se suelen compartir experiencias de soluciones para problemas similares y buscar patrones de diseño para llegar a la solución mas óptima, es en estos momentos cuando entre todo el equipo se dan las pautas para desarrollar el programa y creo que es también aquí cuando se establecen las bases para llegar a la solución más adecuada, para mí TDD es algo en lo que apoyarme que me ofrece mejoras en la productividad, en el testeo y detección precoz de errores y que me permite escribir código de calidad, pero no comparto que hace que la solución sea más simple.

    En cualquier caso respeto tu punto de vista y comparto la mayor parte de las cosas que expones.

    Saludos.

  9. @juan – todo lo contrario, entiendo la Ingeniería del Software pura y dura cuando te aferras a un diseño cerrado desde el principio.
    Implementación y diseño son dos cosas totalmente distintas, estoy totalmente de acuerdo con el proceso que explicas, y soy un aferrimo defensor de Scrum, pero sigo manteniendo mi punto de vista que es que a través de TDD llegas a hacer una implementación sencilla.

    Yo también comprendo tu punto de vista y estoy de acuerdo con todo lo que dices salvo el punto en de vista del TDD, el TDD no es fácil, siempre insisto en lo mismo y como dice Kent Beck, hace falta mucho coraje.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *