Comentarios al hangout “Is TDD dead?”

Después del Hangout sobre TDD de Martin Fowler, Kent Beck y David Heinemeier (https://www.youtube.com/watch?v=z9quxZsLcfo), Christian Soronellas (@theUnic) y yo hemos hecho lo propio y hemos opinado sobre cómo ha ido y hemos incluido algunas reflexiones adicionales. Esperemos que os guste.

  • Carlos Buenosvinos

    Robert C. Martin comenta que una de las mejores maneras de conocer un nuevo componente externo es a través de hacer unit tests sobre él mismo. Unos tests de integración sobre el uso de un componente como Guzzle, pueden permitir tener controladas los cambios de interfaz, compatibilidad, etc.

  • El único jugo que le saco al jangaut es oír de un gurú que TDD es un método que va en contra de la felicidad del programador. Yo tb lo creo y creo tb que es justamente eso lo que genera tanto debate y tanta controversia, y sobre todo pereza. ¿Iba a pasármelo bien programando y tengo que seguir este método tan rígido? es como interpreto el “not pleasurable flow” que decía @dhh. Aun teniendo muchas ventajas, que todos ya saben, va en contra del flujo natural, de lo divertido de programar.

    Para mejorar esto, yo espero que pronto los IDE usen/implementen iTDD (instant TDD) que consiste básicamente en definir el test en modo anotación antes de la función/método, justo encima, y que el test se ejecute continuamente mientras se escribe el código, justo abajo. Así se evita la latosidad de ir cambiando de ventana, de perder de vista código, el test, etc. Bueno, imaginaos las ventajas.

    Desde el punto de vista formal me ha parecido extraordinario el respeto mutuo de los tres. En ningún momento han hecho muecas, ni gestos altivos, ni ningún tipo de actitud gúrica entre ellos. Se agradece.

    • Carlos Buenosvinos

      El concepto de “pasárselo bien” es super relativo. Para gustos los colores y yo me lo paso muy bien haciendo TDD. Es como seguir un protocolo, un baile, cortejar a la solución. Sea como sea, los beneficios sobre la reducción del coste de mantenimiento, el refactoring, el collective ownership, la integración continua, etc. superan, para mí, con creces la pereza.

      Que te guste TDD lo asocio al gusto amargo. De pequeño no te gusta nada, pero a medida que te haces mayor y tus sentido maduran aprecias sabores amargos que al final acaban diciéndote cosas. Tanto que dejas algunos otros más gratuitos, como los dulces. Piensa en el café, el chocolate de verdad, la cerveza, etc.

      Sobre el tema de los IDEs, cualquiera hoy en día implementa el shorcut para lanzar los tests o puedes montarte un watcher que los vaya ejecutando. Merci por el comentario.

      • Sobre las bondades del TDD nadie tiene duda. Sobre cómo convencer a que todos beban café sin azúcar, aprovechando tu símil, ya no lo veo tan claro.

        Felicidades por el blog.

        • Disiento con el símil. Después de haver probado y haver visto cómo el diseño realmente emerge con TDD, a título personal describir la práctica cómo “café sin azúcar” me parece injusto. Tal cómo yo lo veo y llevándolo al mismo lenguaje, para mi desarrollar sería algo así como “comer fresas” (para quién le guste obviamente :) y desarrollar con TDD sería algo así cómo “comerse un buen bol de fresas con nata”. :)

  • Me gusta mucho la humildad con la que Kent Beck explica que lo que el realmente quiere es simplemente trabajar con algo que se pueda testear a si mismo y que provea de un feedback rápido en cualquier cambio. El TDD, es una forma de llegar a eso y si alguien conoce otra forma de llegar al mismo objetivo, pues que bienvenido sea.
    Otra de las cosas que el TDD habilita es el refactoring, el cual a su vez habilita el diseño incremental, siempre cuidando de hacer lo mínimo para que el test pase.

    El TDD es una herramienta que requiere disciplina, y si no puedes seguir esa disciplina, no obtendrás el beneficio completo.

    A mi parecer, DHH tenía su diseño en su cabeza antes de desarrollar el código.
    Uno de sus diseños, era el uso de active records – que viola sin perdón al SRP – el cual es imposible llegar a él siguiendo los pasos del TDD (red, green, refactor) y el diseño incremental.
    Quizás estoy sacando demasiadas conclusiones, pero no creo que sea correcto criticar una forma de trabajar si ni siquiera has podido trabajar correctamente la herramienta.

  • Estoy de acuerdo con lo que decís pero discrepo en la parte de que el test unitario puede ayudar a detectar errors de integración con software de terceros (composer).
    Yo creo que el test unitario es… unitario … sirve para testear Tu código y si tu metodo es el correcto o no.
    Yo creo que para testear integración hay tests de integración/servicio.

    Por lo demás totalmente de acuerdo

  • Pingback: Opiniones sobre “Is TDD dead?” | DWH en BCN()