¿Cuál es el verdadero objetivo de TDD?

A todos aquellos que habéis pensado: “¡Demostrar que mi código funciona!”, lo siento, estáis equivocados. Aunque está asociado al 2º valor principal del desarrollo de software (según Robert C. Martin).

Los valores del desarrollo de software (los dos se deben cumplir):

  1. Flexible (que se adapte fácilmente a los cambios del entorno, refactorización, etc.)
  2. Que haga lo que tiene que hacer (que funcione)

Robert C. Martin considera que el software sea flexible es más importante ya que el gran porcentaje de tiempo nos lo pasamos manteniendo código, leyendo más que escribiendo, desarrollando nuevas funcionalidades, arreglando bugs, etc.

En comparación con otros sectores, la fase de desarrollar software (construirlo) es mucho más barato que diseñar software (pensar en cómo construirlo).

Pensad en construir coches, hay que invertir millones en el diseño del coche y de su proceso de fabricación (planos, simulaciones, etc.) antes de construirlo, principalmente porque un buen diseño ahorrará millones a su fabricante.

¿Qué porcentaje de tiempo invertimos haciendo mantenimiento (bugs y nuevas funcionalidades a un proyecto existente)?

Las estadísticas están entre el 80% y el 90%, lo que significa que representa la gran mayoría del tiempo.

Así que necesitamos una manera o método de poder reducir los costes del tiempo asociado al mantenimiento del software. ¿Se os ocurre alguna?

El verdadero objetivo de TDD es abaratar los proyectos haciendo más barata la fase de mantenimiento. ¿Cómo lo hace?

  1. Garantizando que nuestro código funciona como debería
  2. Ayudando a que la solución y su diseño emerja de los tests (no de un trabajo previo – acordaos de la incerteza del software)
  3. Facilita un diseño desacoplado
  4. A no desarrollar más de lo estrictamente necesario para que los juegos de pruebas pasen (“baby steps” + “until you need it”)

Muchas veces he escuchado desarrolladores diciendo que “no hay tiempo” para desarrollar tests unitarios, que sale más caro, que es una pérdida de tiempo, sólo os dejo una reflexión, ¿cuánto tiempo pasáis usando el debugger? ¿cuánto tiempo pasáis resolviendo bugs que se podrían haber detectado con un test unitario?

Feliz fin de semana!

  • Amén!

    De hecho, desgraciadamente, entender el porqué es sencillo, incluso hacer entenderlo a los “jefes” (aka negocio) lo realmente jodido es hacerlo entender a determinados perfiles de desarrolladores.

    Salu2

    • Carlos Buenosvinos

      Cierto, cuesta entender cómo hay tantos developers que no entienden que TDD es el estándar de facto y una skill obligatoria para un developer profesional y serio.

  • Gonzalo Ayuso

    Has dado en el clavo. El verdadero objetivo es abaratar costes reduciendo el mantenimiento. El problema es que es muy difícil medir esto. Lo fácil es medir el tiempo que se tarda en sacar algo a producción, pero medir el tiempo (a.k.a. dinero) que se gasta en la retahíla de bugs que explotan como bombas de relojería en cualquier momento puede ser muy complicado. Lo fácil es decir TDD es lento. Además, no nos engañemos, el TDD es complicado llevarlo a cabo. Los conceptos son sencillos pero como toda metodología dominarla y sacarle todo el potencial requiere experiencia y esfuerzo. Como escuché por ahí, el TDD estricto es duro, casi utópico. Requiere un equipo comprometido (y bueno) y una dirección que tenga interiorizada la metodología, si no es muy fácil sacarle defectos (que son más defectos nuestros por no saber como hacerlo, que defectos del TDD propiamente dichos).

    Lo mejor para empezar a ver el potencial del TDD son las Katas. Yo recuerdo cuando comencé con los Katayunos hace unos añitos. La primera vez que experimenté en mis carnes eso de que “el diseño emerge con TDD” me quedé impresionado, y no digo nada lo que es refactorizar código con una buena cobertura de tests. Vale esto último no es TDD estrictamente hablando. Se puede conseguir con tests de integración realizados a posteriori, pero es un efecto colateral impresionante que nos da TDD.

    Otra reflexión que tengo sobre TDD es que todo son ventajas. En mi caso no consigo usarlo 100% en el día a día, lo reconozco. En mis pet-projects, katas y similares si, pero luego que si legacy code, que si BBDDs, que si tal, que si cual … De todas formas aún cuando no lo uso mi mente (que ya está infectada por el virus) sigue con el patrón “red-green-red-green-refactor” (aunque el refactor sin test da miedito) y desacoplar como si no hubiese mañana. Además pienso que lo realmente importante es SOLID. TDD ayuda (mucho) a hacer SOLID, pero si eres capaz de hacer SOLID sin TDD, pues adelante.

    • Carlos Buenosvinos

      Fantástico comentario! Nosotros en Emagister hacemos formaciones cada viernes y todas las últimas son Katas (algunas de ellas las voy publicando en el blog) con TDD y Pair Programming en modalidad ping-pong.

      Al principio, costaba que se entendiera el beneficio de TDD, ponerlo en práctica, pero ahora, el beneficio es evidente, el diseño mejora, etc.

      Tal y como decía Oriol, cuesta que algunos developers lo pillen (TDD en modo autodidacta es durillo) pero si los CTOs, tech leads o simplemente otros developers que sí tienen la dinámica puede evangelizar al resto, el mundo será un sitio mejor :)

  • Es interesante que publiquéis, si podéis/queréis, los motivos por los cuales algunos developers no entienden que TDD es magnífico. Quizá tiene algunos argumentos que valen la pena tener en cuenta.

    • Carlos Buenosvinos

      Me encantaría que alguien publicara sus motivos por los cuales no les gusta TDD, pero no creo que se atrevan. Mi experiencia me dice que es por un tema de desconocimiento y miedo, de no saber cómo empezar (algún mentor o guía) o de que su responsable no lo defiende. Si el CTO de una empresa no entiende los beneficios de TDD es difícil que se lo pida a su equipo y los que no lo conocen lo trabajen.