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.

Ejemplo mejorado de doble de test

El artículo anterior trataba de un ejemplo de doble de test de tipo stub.
El stub se llama StubUserDAO e implementa el método findUserBy, devolviendo siempre el mismo objeto.

Si quisiéramos que findUserBy devolviera otro User tendríamos que crear otra clase como StubUserDAO que devolviera ese User, ya que StubUserDAO siempre devuelve el mismo User.

Como puedes imaginarte, no es una solución flexible, ya que casi con cada nueva prueba tenemos que crear una clase parecida a StubUserDAO.

Para solucionar este problema, en este artículo te quiero presentar la versión de un doble de tipo de tipo stub:

La principal diferente, de este doble de test en relación con el anterior es que podemos cambiar el User que va a devolver el método findUserBy.
Podemos cambiar el usuario que devuelve el método utilizando el método.
En el código, el test should_throw_exception_when_passwords_are_different_version1 hace que que StubUserDAOv2 devuelva un usuario con contraseña “other_password”, y el test should_throw_exception_when_passwords_are_different_version2 hace que devuelva un usuario con contraseña “another_contraseña”.

Como he comentado al principio, la principal ventaja de este tipo de stub es flexible ya que permite devolver diferentes tipos de valores sin tener que crear una nueva clase.
Otra ventaja de este tipo de stub es que la configuración del stub para que devuelve el usuario es el propio stub. Al tener la configuración en el stub queda claro lo que estamos probando, porque podemos ver la contraseña del usuario y la contraseña que utilizamos en el signin al mismo tiempo ya que están al lado.
Esto simplifica mucho el comprobar que es lo que fue mal cuando el test falla.

Un par de comentarios sobre el ejemplo:

  • Recuerda inicializar siempre stub. Así nos evitamos desagradables efectos secundarios como que si ejecutas todos los test no todos pasan, pero si ejecutas uno en concreto pasa (también puede ser el efecto contrario). Esto es debido a que un test comparte usuario con otro test a través del stub.
  • Hay que utilizar como atributo en la clase de test el objeto StubUserDAOv2, y no UserDAO. Parece una tontería pero la primera vez que creé el stub, me quede un buen rato atascado porque Eclipse me decía que no podía utilizar el método setUserFoundByEmail y era porque utilicé UserDAO:

 

Ejemplo de código Java hecho con TDD (con historia incluida)

programming challenges
Imagen de http://www.programming-challenges.com/

Hace algunos meses estaba buscando un nuevo trabajo como programador, y una de las cosas que suelen pedir en Holanda, para medir las habilidades de los candidatos, es un ejemplo de código.

Por lo que he vivido durante esos meses, hay un número grande de empresas que no solo quieren un ejemplo de código sino que te piden resolver un problema concreto en un tiempo determinado.

En una de las empresas, el problema que me pidieron resolver me pareció interesante. El problema era el construir una aplicación que calculara la fecha en la que un cliente tendría su pedido listo, teniendo en cuenta la fecha actual del sistema y el tiempo que se tarda en realizar la tarea.

El ejercicio lo hice completamente utilizando TDD y me costó (creo recordar) dos semanas, utilizando horas de mi tiempo libre, ya que tenía trabajo.  Lo tuve que hacer dos veces, debido a que la primera vez, la solución que había elegido en un punto me estaba complicando el añadir más test sin romper los test anteriores.

Después de enviar mi solución al problema, me quedé a la espera de recibir información de si les había gustado, y si era así, si me invitaban a una entrevista. Estaba bastante ansioso de recibir la respuesta porque terminé bastante contento de como me quedó.  No es que sea perfecto el código, sino que era la primera vez que enseñaba mi código a alguien después de haber aprendido TDD.

Nunca recibí ningún tipo de feedback sobre el código y ni siquiera se dignaron en decirme nada de porqué se estaban retrasando tanto.

Ya que no he recibido ningún tipo de feedback y que me quedé con ganas, lo he publicado en GitHub y estaré más que encantado de recibir cualquier tipo de comentario.

No he añadido muchos detalles sobre cual es el problema porque no quiero dar pistas sobre cual era la compañía, pero creo que los comentarios que añadí en el código y los test hacen que resulte fácil de entender.

El enlace al código es:

https://github.com/kikers25/programming_challenge

El ejercicio está hecho con maven y java 7. Las librerías que utilicé son: JUnit 4, hamcrest, Joda-Time y pitest.
Pitest es una librería que mide la cobertura del código utilizando “mutation testing”. Hay un artículo en español muy bueno que explica muy bien qué es “mutation testing”:

http://testeandosoftware.com/mutation-testing/