Ciclo TDD: versión extendida

Imagen de http://www.agilenutshell.com/test_driven_development

Cuando a alguien se le explica por primera vez test driven development (TDD) lo primero que se le cuenta es su ciclo de desarrollo, que consiste en:

1. Escribir un test que falle
2. Escribir código de producción que haga que el test pase
3. Refactoriza el código

Estos pasos son un gran resumen de las principales tareas que hay que hacer en TDD pero para alguien nuevo en TDD no es suficiente. Voy a extender el mismo ciclo de desarrollo añadiendo más detalles. La mayoría de los pasos vienen de la siguiente página:

http://c2.com/cgi/wiki?TestDrivenDevelopment

Versión extendida

1. Selecciona un test. Busca un test que sea fácil de implementar pero que permita progresar lo máximo posible en la implementación
2. Piensa cómo quieres comprobar que el test pasa
3. Piensa qué debe ocurrir cuando todo va bien y cuando ocurre algo inesperado (excepciones). Por ejemplo, cuando hay problemas en la base de datos.
4. Escribe el test teniendo en cuanta cómo quieres que sea la API. Con la API me refiero al nombre del método, a sus parámetros y al valor a devolver
5. Haz que compile el código creando las clases y métodos que has escrito en el test. Los métodos deben devolver un valor, el que consideres que es el de por defecto
6. Comprueba que el test no pasa
7. Escribe el mínimo código de producción que hace que todos los test pasen. Si, el mínimo.
8. Si es necesario, mejora el código sin cambiar su comportamiento. O lo que es lo mismo, refactoriza el código
9. Comprueba que todos los test pasan

Notas

Teniendo en cuenta los pasos de la versión extendida, cuando escribimos el test ya hemos decidido qué vamos a hacer, cómo vamos a testearlo y cómo será su API. Luego dirán que con TDD no se piensa :)

Para gente con cero experiencia con TDD seguramente lo que les resulte extraño es que al escribir el
primer test, el código no compila y tendremos que crear todas las clases y métodos necesarios para que el código compile. Es una forma diferente de pensar, por lo que es necesario tiempo para asimilarla.

Consejo

Un muy buen consejo de Kent Beck en su libro TDD by example es el mantener una lista de los tests que quieres implementar. Así, cada test o prueba se convierte en una tarea a realizar y cada vez que terminas una es un ciclo TDD terminado y te acerca a la nueva funcionalidad que estás buscando.

Si eres indispensable estas haciendo mal tu trabajo

Imagen de http://www.newyork.com/

Te quieres ir de vacaciones tres semanas y se lo comentas a tu jefe. Te dice que ahora imposible porque el proyecto en el que estás trabajando eres el único que puede hacer una parte que es crítica. Al escucharle te sientes decepcionado al perderte tus vacaciones pero a la vez orgulloso porque eres una persona importante en tu empresa y porque eres imprescindible, ya que sin ti tu empresa no funciona.
Si este es tu caso no deberías sentirte orgulloso porque no estás haciendo bien tu trabajo.

Hay muchas razones por la que eres imprescindible pero seguramente que lo que está sucediendo es que eres la única persona en tu empresa que tiene el conocimiento de cómo realizar esa tarea.
Hay muchas razones por lo que esto puede suceder. Algunas son:

• La tarea es de vital importancia y no confías en nadie para hacerla.
• Tú eres la única persona con los suficientes conocimientos sobre el tema para entender el que hacer si surgen problemas.
• Tus compañeros no son lo suficiente buenos o profesionales para hacer (o eso es lo que tú piensas).
• No has tenido tiempo en compartir lo que sabes porque ha surgido algo urgente.
• Has pensado que no era importante el compartirlo.
• Tu jefe te ha dicho que es una perdida de tiempo.
• En un caso extremo de egoísmo, has decido el no compartirlo para convertirte en imprescindible y que no te puedan echar.

En cualquiera que sea tu caso no estás pensando en tus compañeros, ni en tu empresa y ni siquiera en ti.

De primeras te has quedado sin vacaciones, así que la playa y los mojitos tendrán que esperar. Además te has quedado sin aprender, porque no se tu pero cada vez que comparto información con mis compañeros siempre aprendo algo nuevo de ellos. Puede que aprenda algo pequeño pero siempre aprendo, y si eres informático como yo el aprender debería ser algo muy importante porque a los pocos años te quedas desfasado.
Si no eres informático el aprender también debería ser importante porque así te podrá diferenciar de tus compañeros y tener más posibilidades de destacar.

Desde el punto de vista de tus compañeros, toda la información debe estar compartida al menos por dos miembros de tu equipo. Así sí uno de ellos está enfermo, está de vacaciones o deja la empresa siempre habrá otra persona con esa información.
Por ejemplo, imagínate que has estado enfermo y debido a ello tu equipo ha estado casi parado. Lo que ha provocado que el proyecto no se ha terminado a tiempo y tu empresa ha perdido tiempo y dinero. Y todo ello por tu culpa, por no hacer bien tu trabajo y no compartir lo que sabes con tus compañeros.

Si no te he convencido y crees que eres intocable porque eres el único con esos conocimientos, recuerda que el mundo de la informática todo cambia muy rápidamente y que en 2, 5 o 10 años ese conocimiento no valdrá nada, tus jefes querrán despedirte, ninguna empresa querrá contratarte y lo vas a pasar mal. El que avisa no es traidor.