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?