Trucos al aplicar TDD

La semana pasada estuve leyendo una entrada del blog "the urban canuk, eh" que trataba sobre Test-Driven Development y he de admitir que me parecio una entrada bastante interesante con una serie de consejos que considero recomendables. Me gustaría hacer un resumen de los puntos que me parecieron más interesantes.

Utilizar nombres consistentes en las clases de tests.

Es conveniente que todas la clases de tests tengan un sistema de nombres consistente y homogéneo, por ejemplo que todas ellas tengan nombres como <TargetClass>TestCase (es decir el nombre de la clase que deseamos probar seguido de TestCase), y no que una se llame LoginTest, otra RepositoryTestCase, o lo que es peor aún que incluso ni siquiera se haga referencia a que es una clase de tests. Esto logrará que cualquier persona que trabaje en el proyecto pueda localizar los tests de forma sencilla y rápida.

Usar los mismos espacios de nombre para tests y código a probar.

He visto más de una vez que hay mucha gente que coloca las clases a probar en un paquete y las clases de tests en otro paquete con nombre diferente, con esto no quiero decir que no sea posible o no se pueda hacer, pero creo que si se ha de evitar en la medida de lo posible. En mi experiencia personal he llegado a la conclusión de que la mejor práctica es dividir entre el código de tests y el código que se desea testear en dos localizaciones diferentes, por ejemplo /src para el código fuente y /test para el código de tests (por ejemplo separado en distintas carpetas de código). Pero la estructura de paquetes ha de ser la misma para facilitar la busqueda en caso necesario.


Usar siempre los mismos nombres para los métodos de setup y teardown.

Con JUnit hay una serie de métodos especiales anotados con anotaciones como @Before o @After y aunque el método puede tener un nombre seleccionado por el programador, es recomendable que los nombres seleccionados para estos métodos sean siempre los mismos para que el código sea lo más homogéneo posible.

Nombrar los métodos de test según la funcionalidad a probar.

Dado que en TDD el primer paso es crear los tests para luego crear el código fuente, lo más normal es crear los métodos de test con un nombre que indique la funcionalidad que se desea probar. En general, es común que un mismo SUT (subject under test) tenga más de un test asociado, por lo que usar el nombre de la funcionalidad a probar documenta mejor el sistema y da una idea más concreta de lo que hace.

Documentar brevemente los métodos de test más complejos.

Hay veces que el dominio en el que trabajamos es muy complejo y el test no queda absolutamente claro, en estos casos es necesario hacer un breve comentario de lo que se desea probar en el código, para que la persona que venga detras sepa lo que estamos haciendo.

Si necesitas utilizar más de un par o tres de línea para documentar un método de test o necesitas documentar absolutamente todo porque nada queda claro, planteate que a lo mejor estas haciendo algo mal y es mejor darle un par de vueltas antes de continuar.

No crees implementaciones antes de los tests.

Si creas una implementación y luego creas los tests para esa implementación, estas haciendo pruebas unitarias, pero eso no es TDD. Intenta crear los tests antes porque en caso contrario pierdes todas las ventajas que aporta usar TDD.

Para acabar me gustaría hacer algo de publicidad sobre el libro escrito por Carlos Blé y sus colaboradores, para todas aquellas personas interesadas en el tema de TDD :)