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.