{"id":2048,"date":"2020-12-31T19:10:00","date_gmt":"2021-01-01T01:10:00","guid":{"rendered":"\/?p=2048"},"modified":"2024-04-05T16:10:37","modified_gmt":"2024-04-05T22:10:37","slug":"introduccion-desarrollo-guiado-especificacion-tdd","status":"publish","type":"post","link":"https:\/\/pensemosweb.com\/en\/introduccion-desarrollo-guiado-especificacion-tdd\/","title":{"rendered":"Introducci\u00f3n a desarrollo guiado por especificaci\u00f3n TDD"},"content":{"rendered":"

En realidad TDD<\/strong> significa Desarrollo guiado por pruebas<\/strong>, del ingl\u00e9s Test Driven Development<\/strong>. Lamentablemente es un nombre que no le hace justicia, lo que realmente gu\u00eda al desarrollo siguiendo esta pr\u00e1ctica, son las especificaciones o comportamientos.<\/p>\n\n\n\n

Ya s\u00e9, ya s\u00e9, para la gente que sabe que es BDD seguro se pregunta, \u00bfGuiado por comportamiento?, \u00bfEso no es BDD?, pero el contenido de esta publicaci\u00f3n clarificar\u00e1 la estrecha relaci\u00f3n entre TDD y BDD. Mostraremos una perspectiva en la que en esencia, son lo mismo.<\/p>\n\n\n\n

Origen de TDD en la vida<\/h2>\n\n\n\n

Una de las caracter\u00edsticas principales y de hecho el primer paso cuando se aplica desarrollo guiado por pruebas es el entender bien el problema a resolver. Es por eso que se escriben las pruebas primero, esta idea ha existido desde que el ser humano hace cualquier tipo de trabajo, ejemplo:<\/p>\n\n\n\n

Un cazador ense\u00f1a a su hijo como cazar una cebra y le indica que el mejor lugar para clavarla es justo debajo de la oreja, donde puede atravesar su cr\u00e1neo, pero ese es un tiro muy dif\u00edcil. Le dice que el tiro m\u00e1s facil es “Apuntar a las rayas que la cebra tiene en el pecho”. Mientras el padre dibuja las rayas en el tronco de un \u00e1rbol<\/em> (simplicidad<\/strong>).<\/p>

\u2013 Sigue practicando el tiro a una distancia de 20 pasos hasta que claves la lanza correctamente\u201d, luego -\u201cNo espera, sost\u00e9n la lanza as\u00ed\u201d, m\u00e1s tarde \u2013 \u201cSi, as\u00ed est\u00e1 mejor, continua as\u00ed\u201d \u2026 \u2013 \u201cAhora, p\u00eddele a tu t\u00edo que te ense\u00f1e c\u00f3mo hacer que la cebra se acerque a una distancia de 10 pasos<\/em>” (iterativo e incremental, lotes peque\u00f1os, ciclo de retroalimentacion<\/strong>) <\/p>Bob Allen de <\/strong>codecraftsmansaturdays<\/strong><\/a><\/cite><\/blockquote>\n\n\n\n

El objetivo del padre y del hijo es que este \u00faltimo pueda cazar una cebra (enfoque<\/strong>). <\/p>\n\n\n\n

Lo ideal es clavar la cebra justo debajo de su oreja. Esto es una tarea dif\u00edcil para el hijo, entonces utilizando un proceso iterativo e incremental<\/strong>, se empieza con el paso m\u00e1s f\u00e1cil hasta ahora conocido. El paso es apuntar al pecho de la cebra a una distancia de 20 pasos (simplicidad<\/strong>).<\/p>\n\n\n\n

Despu\u00e9s surge otro inconveniente, sostener la lanza correctamente, por eso se trabaja en ello. Posteriormente surge otra cosa, hacer que la cebra se acerque hasta 10 pasos de distancia (lotes peque\u00f1os, iteraciones y vamos incrementando hasta la meta<\/strong>). Aunque no se menciona la raz\u00f3n, podemos suponer que, el padre se quiere asegurar que el hijo pueda clavar la cebra en el primer tiro<\/p>\n\n\n\n

Ahora bien, de momento se cumple el objetivo (enfoque<\/strong>), cazar a una cebra, por lo que el padre y el hijo pueden detenerse ah\u00ed. Conforme se empieza a trabajar en la soluci\u00f3n, muchas veces esta es mucho m\u00e1s simple de lo que se pensaba en el inicio.<\/p>\n\n\n\n

El punto es que este proceso iterativo e incremental permite ahorrarnos tiempo, dinero y esfuerzo implementando una soluci\u00f3n mucho m\u00e1s simple. Y si te preguntas cu\u00e1l es la soluci\u00f3n complicada, esa es la de “clavarla justo debajo de la oreja”<\/em>.<\/p>\n\n\n\n

TDD est\u00e1 basado en principios \u00e1giles y el manifiesto<\/h2>\n\n\n\n

Todo este proceso natural e inconsciente sobre como clavar a una cebra, descrito en la secci\u00f3n anterior, gira alrededor de principios \u00e1giles.<\/a> Y estos principios a su vez se relacionan fuertemente con el manifiesto \u00e1gil.<\/p>\n\n\n\n

  1. Simplicidad<\/strong>, el arte de maximizar el trabajo no realizado, es esencial.
    1. Algunos conocer\u00e1n los principios KISS y YAGNI en programaci\u00f3n.<\/li>
    2. As\u00ed tambi\u00e9n algunos habr\u00e1n escuchado NO DESPERDICIAR de Lean manufacturing<\/li>
    3. LOTES PEQUE\u00d1OS en cada iteraci\u00f3n, de Lean Manufacturing<\/li><\/ol><\/li>
    4. Ciclo de retroalimentaci\u00f3n<\/strong><\/li>
    5. Proceso iterativo e incremental<\/strong><\/li><\/ol>\n\n\n\n

      Estos son los m\u00e1s importantes desde mi punto de vista y tal vez los que m\u00e1s podemos notar en el d\u00eda a d\u00eda.<\/p>\n\n\n\n

      Origen de TDD en programaci\u00f3n<\/h2>\n\n\n\n

      Para darte una idea del origen real de TDD, voy a citar varias fuentes.<\/p>\n\n\n\n

      No ten\u00edamos manuales para ENIAC. Aprendimos a programar estudiando los diagramas de bloques l\u00f3gicos. Que bendici\u00f3n. Desde el principio supe c\u00f3mo funcionaban las computadoras. Nos ganamos el respeto de los ingenieros desde el principio porque realmente sab\u00edamos lo que est\u00e1bamos haciendo y pudimos depurar mejor que ellos porque ten\u00edamos nuestros programas de prueba<\/strong> y nuestro conocimiento de la computadora.<\/em><\/p>Betty Jean Jennings Bartik, ENIAC programmer 1946<\/em><\/cite><\/blockquote>\n\n\n\n

      El primer ataque al problema puede realizarse antes de comenzar la codificaci\u00f3n. Para determinar completamente la precisi\u00f3n de las respuestas, es necesario tener un caso de verificaci\u00f3n calculado a mano con el cual comparar las respuestas que luego ser\u00e1n calculadas por la m\u00e1quina. <\/em><\/p>

      Esto significa que las m\u00e1quinas de programas almacenados realmente nunca se utilizan para un problema de una sola vez. Siempre debe haber un elemento de iteraci\u00f3n para que valga la pena. Los c\u00e1lculos manuales se pueden realizar en cualquier momento durante la programaci\u00f3n. Sin embargo, con frecuencia las computadoras son operadas por expertos en computaci\u00f3n para preparar los problemas como un servicio para ingenieros o cient\u00edficos. <\/em><\/p>

      En estos casos, es muy deseable que el “cliente” prepare el caso de verificaci\u00f3n, en gran parte porque tal procedimiento puede se\u00f1alar errores l\u00f3gicos y malentendidos entre el programador y el cliente. Si el cliente va a preparar la soluci\u00f3n de prueba, lo mejor para \u00e9l es comenzar mucho antes del problema real, ya que para cualquier problema importante se necesitar\u00e1n varios d\u00edas o semanas para calcular la prueba<\/em><\/p>Digital Computer Programming<\/em>, D.D. McCracken, 1957<\/cite><\/blockquote>\n\n\n\n

      Otro dato, de la \u00e9poca de John Von Neumann, <\/strong>en una entrevista realizada a Gerald. M. Weingberg por Michael Bolton<\/strong><\/p>\n\n\n\n

      Jerry: No llam\u00e1bamos a esas cosas por esos nombres en ese entonces, pero si miras mi primer libro (Computer Programming Fundamentals<\/a>, Leeds & Weinberg, first edition 1961 \u2014MB) y muchos otros desde entonces, ver\u00e1s que siempre fue as\u00ed como pensabamos que era la \u00fanica forma l\u00f3gica de hacer las cosas. Lo aprend\u00ed de Bernie Dimsdale, quien lo aprendi\u00f3 de von Neumann.<\/em><\/p>

      \u2026 luego me encontr\u00e9 con Bernie (en 1957), quien me mostr\u00f3 c\u00f3mo la gente verdaderamente inteligente hac\u00eda las cosas. Mi ego estaba un poco en shock al principio, pero luego me di cuenta de que si von Neumann hac\u00eda las cosas de esta manera, yo deber\u00eda hacerlo.<\/em><\/p>

      John von Neumann<\/strong> fue mucho m\u00e1s inteligente de lo que yo ser\u00e9 jam\u00e1s, o de lo que la mayor\u00eda de la gente ser\u00e1, esto significa es que debemos aprender de \u00e9l \u2026<\/em><\/p>Geral M. Weinberg<\/cite><\/blockquote>\n\n\n\n

      La descripci\u00f3n original de TDD estaba en un libro antiguo<\/a> sobre programaci\u00f3n. El libro dec\u00eda, tome la cinta de entrada, escriba manualmente lo que espera en la cinta de salida, luego programe hasta que la cinta de salida real coincida con la salida esperada.<\/em><\/p>

      Despu\u00e9s de escribir el primer marco xUnit en Smalltalk, record\u00e9 haber le\u00eddo esto y lo prob\u00e9. Ese fue el origen de TDD para m\u00ed. Al describir TDD a programadores mayores, a menudo escucho: \u201cPor supuesto. \u00bfDe qu\u00e9 otra manera podr\u00edas programar? ” Por lo tanto, me refiero a mi papel como “redescubrir” TDD.<\/em><\/p>Kent Beck<\/em><\/cite><\/blockquote>\n\n\n\n

      Si analizamos un poco estos \u00faltimos datos, en esa \u00e9poca se necesitaban ejecutar pruebas y resolver el problema en papel antes de correr el programa en la computadora porque era muy tardado volver a ejecutar el programa despu\u00e9s de una falla ya sea por el tiempo de \u201cejecuci\u00f3n\u201d o porque las m\u00e1quinas de esa \u00e9poca simplemente no eran tan sofisticadas como las de hoy en d\u00eda.<\/p>\n\n\n\n

      Todo esto nos indica la importancia de las pruebas y as\u00ed no retrasar el tiempo necesario para que la soluci\u00f3n funcione correctamente y con menos esfuerzo, en la actualidad no ha cambiado mucho, eso s\u00ed, tenemos otros problemas, adem\u00e1s el software que se desarrolla hoy en d\u00eda tiene mayor escala y las funcionalidades son m\u00e1s sofisticadas. <\/p>\n\n\n\n

      Otro punto que nos ense\u00f1an estos datos, es que la comunicaci\u00f3n entre los involucrados desde un principio es importante para evitar errores l\u00f3gicos y malentendidos entre el cliente y el programador. Aqu\u00ed los clientes tambi\u00e9n pueden ser  usuarios, personas de UX y product owners.<\/p>\n\n\n\n

      Lo descrito por Kent Beck es muy interesante, programadores m\u00e1s viejos est\u00e1n de acuerdo en que no existe una mejor manera de programar que la de escribir las pruebas primero.<\/p>\n\n\n\n

      En conclusi\u00f3n, estos datos nos abre los ojos a que las pruebas siempre han sido parte del proceso de dise\u00f1o y codificaci\u00f3n. Y que se hacen lo m\u00e1s antes posible (test-first programming)<\/p>\n\n\n\n

      OK, \u00bfQu\u00e9 es TDD?<\/h2>\n\n\n\n

      Es una disciplina que te permite eliminar el miedo a modificar el c\u00f3digo de un software, lo que resulta en la limpieza constante del c\u00f3digo, por lo que se asegura que el software escale de manera fluida, sin retrasos y dolores de cabeza. Permitiendo tener un software lo suficientemente flexible para poder adaptarse a cualquier cambio.<\/p>\n\n\n\n

      TDD es una pr\u00e1ctica \u00e1gil, por consiguiente basada en principios \u00e1giles que nos permite tener una gu\u00eda en el desarrollo de software para nunca perder el enfoque.<\/p>\n\n\n\n

      TDD se basa en la mentalidad de prevenir defectos en lugar de resolverlos despu\u00e9s, es obvio que no se puede prevenir todos los casos, pero si un gran n\u00famero con un conjunto de pruebas bien hechas.<\/p>\n\n\n\n

      Hist\u00f3ricamente hablando, ha probado ser en la gran mayor\u00eda de los casos, la mejor manera de crear productos de calidad. Significa Desarrollo guiado por pruebas (Test Driven Development), pero como mencionamos antes, la palabra especificaci\u00f3n<\/strong>, la describe mejor, algo as\u00ed como SDD<\/strong>, Specification Driven Development.<\/p>\n\n\n\n

      Red-Green-Refactor<\/h3>\n\n\n\n

      En la pr\u00e1ctica, consiste en tres pasos segun Kent Beck:<\/p>\n\n\n\n

      1. RED<\/strong>. Escribe una peque\u00f1a prueba que no funcione, tal vez ni siquiera compile al principio<\/li>
      2. GREEN<\/strong>. Haz que la prueba funcione r\u00e1pidamente, cometiendo los pecados necesarios en el proceso.<\/li>
      3. REFACTOR<\/strong>. Elimina todo el c\u00f3digo duplicado creado<\/li><\/ol>\n\n\n\n

        <\/p>\n\n\n\n

        Ahora bien, cu\u00e1les son los beneficios principales:<\/p>\n\n\n\n