TDD con lenguajes dinámicos y estáticos

Hoy he visto los vídeos de Hernan Wilkinson que comparan la práctica de TDD cuando se lleva a cabo con un lenguaje estático y otro dinámico.

En mi caso he practicado TDD con Java, C# y Python. Realmente encuentro que cuando uso Python voy más rápido que con los otros dos como apunta Hernan. Sin embargo hay casos en los que se sale ganando con ellos. Por ejemplo cuando integramos distintas capas del software, lo cual ya no sería hacer TDD sino escribir tests de integración, noto  que el número de bugs disminuye en lenguajes fuertemente tipados porque a estos niveles los bugs suelen ser cuestiones como que la API no es exactamente tal como se le intenta consumir. Con Python no te enteras hasta que ejecutas el código mientras que con Java el compilador te avisa. Como digo, los problemas de integración con Python suelen ser discordancias en el uso de la API.

Esto significa que si NO hacemos TDD correctamente, el resultado sería peor utilizando Python que Java. Es decir, si los desarrolladores tienen poca experiencia y no hacen TDD como debe ser, yo les obligaria a usar Java. En cambio, si el desarrollador se preocupa por hacer las cosas lo mejor posible, estoy convencido de que con Python sale ganando. Tiene sentido que las "cárnicas" que sólo quieran code monkeys, no usen lenguajes como Ruby o Python.

Cuando practico TDD lo mejor que puedo, resulta que el código acaba siendo el mismo, tanto si lo hago en Java como si lo hago en Python. TDD es una herramienta de diseño y ambos lenguajes utilizan el paradigma de la orientación a objetos. Dadas estas premisas parece natural que ambas implementaciones converjan a la misma solución.

En el video de Hernan, parece que a medida que se implementa, en Java se hace más costoso que en Smalltalk. En mi experiencia esto no es así. Lo primero porque yo no empiezo usando "Object" para la categoria, sino que directamente hubiese apostado por una clase propia, "Category". Es verdad que en el refactoring, Hernan lo hace, pero lo que más me gusta de TDD es que me permite diseñar conforme escribo, con lo cual directamente elijo qué clases quiero y qué quiero que tengan. Si no fuese así, TDD tendría menos sentido.

Por último decir que los nombres de los tests me parecen esenciales. En el video se usa Test1, Test2, aludiendo a no tener que pensar en el nombre, cuando en realidad el autor está diciendo que quiere comprobar que el objeto "Pc" forma parte de la categoría "Electronic":   "PcBelongsInElectronic" es un nombre ideal y sin tener que pensar.

El libro de Clean Code de Robert Martin se puede resumir en enseñanzas: No dejes código duplicado y busca nombres adecuados. Los nombres son mas importantes de lo que parece 🙂

Que experiencia has tenido tu?

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • hernan

    Que tal Carlos, gracias por tus comentarios sobre el video.
    Hay un par de cosas que me gustaría aclarar:
    1) Respecto de tu comentario de usar la clase Category de entrada, tené en cuenta que la intención del ejemplo es mostrar el impacto que tiene cambiar el tipo de un objeto y por otro lado, si haces TDD “al pie de la letra” no tiene sentido crear una clase que no sabes que vas a necesitar, por eso también en el ejemplo utilicé con Ojbect, de lo contrario estaría adelantandome a lo que realmente se necesita y podría estar creando abstracciones de más.
    2) Estoy de acuerdo que los nombres de los tests son esenciales, por eso aclaré que no iba a utilizar un nombre “sin significado” (no un mal nombre) y que dejaba la parte de poner de hacer los refactorings para cuando tuviese buena información para hacerlo. Si de entrada los hubiese llamado como decís, de vuelta estaría haciendo futurología… Por otro lado, un buen nombre para el primer test no sería “PcBelongsInElectronic” sino “ProductsBelongToOneCategory”, el hecho que sea pc y electronica es sólo anecdótico.

    Un abrazo
    Hernan.

  • http://carlosble.com Carlos Ble

    Entiendo tus razones Hernan. Lo que pasa es que queria hacer incapie en lo de los nombres porque hay pocos recursos en castellano sobre TDD y ya que has hecho los videos me parecia importante resaltar que la gente no debe (en mi opinion) de tomarse la licencia de no usar nombres adecuados en cada momento. Mi experiencia tambien es que la mayoria de las cosas que no se programan en el momento, luego nunca se corrijen.

    Gracias por compartir tu opinion 🙂

  • http://blog.delucas.com.ar Lucas

    Hola! Hace un tiempo vengo enseñando el TDD-101 en un par de universidades, y siempre me viene funcionando.
    Generalmente comienzo como dice Carlos. De hecho, escribo el test y éste cambia muy poco. Reconozco que no es rigurosamente TDD, pero lo considero la mejor manera para comenzar a verlo.
    Quizas le de otra oportunidad al método Wilkinson 😉

  • http://www.mah-jongs.com mah jongs

    I simply had to appreciate you yet again. I am not sure the things I might have made to happen without those tactics provided by you over such a concern. It previously was the daunting problem in my opinion, however , discovering the very expert avenue you processed that made me to leap over joy. I will be grateful for this work and as well , have high hopes you realize what a great job that you are undertaking instructing others with the aid of your blog. I am certain you haven’t got to know any of us.