Aquí va un ejemplo de TDD

Aquí va un ejemplo de TDD.

Hace tiempo que quería escribir esto y con el fin del horario de verano resulta que tengo una hora extra así que aquí va.

No voy a extenderme mucho en que es el TDD ( desarrollo dirigido por pruebas ) ni por que es importante, ni como usar un framework como JUnit o TestNG, espero que baste con decir que el efecto más importante que tiene el TDD es que una vez terminado el desarrollo, el código ya tiene pruebas automatizadas.

Me parece que un ejemplo suficientemente sencillo y no tan trivial puede ser construir un evaluador de expresiones booleanas, donde se pase un string como:

y nos diga que el resultado es

Sé que un evaluador como este puede ser escrito muy fácilmente con un generador lexico, pero no es la idea ahora. La idea es hacer un ejemplo que sea suficientemente interesante.

Antes de empezar repasemos cual es el ciclo de vida del TDD:

• Agregar una prueba ¡¡ANTES!! ( esto es importante )
• Correr las pruebas y ver si el la nueva prueba falla
• Escribir código *mínimo y suficiente*para hacer que la prueba pase
• Correr las pruebas y ver si no hemos roto alguna prueba existente
• Hacer refactoring
• Repetir hasta quedar satisfechos

Entonces empecemos,

1.- Agregamos la primera prueba:

2.- Vemos que falle.

Un momento, creo que eso fue demasiado demasiado breve. Ni siquiera compila, por que aún no existe la clase   pero aquí hay algo importante; al crear la prueba, voy a describir como quiero que se llame mi clase, como es que va a ser usada y que métodos va a tener, que parámetros y todo ¡mientras la pruebo!. Es algo extremo ya sé, no en vano el TDD forma parte de la metodología de programación extrema ( XP ). Si cambiamos de opinión en el futuro ( más bien, si las pruebas nos hacen cambiar de opinión ) podemos sin mucho temor, cambiar alguna firma o método y luego volver a correr las pruebas y podemos ver que es lo que se rompe. Aún así, por el momento podemos decir que ejecutamos bien el paso 2.

3.- Escribir el código mínimo para que pase.

En este punto es demasiado sencillo. Como soy muy positivo, nomás devuelvo "true"

4.- Correr las pruebas existente.

Corremos las pruebas y vemos que todo este en verde:

Parecerá ridículo que si mi método regresa   "hardcodeado" yo diga que ya funciona, pero la verdad es que la funciona para el conjunto de pruebas que tengo. Es como si dijera, "así es como la pretendo usar". Obvio, no cumple con todos mis expectativas, pero la idea es que no codifique nada más de lo que estoy probando, es decir, hay que evitar hacer suposiciones, evitar adelantar código, evitar pensar *"Y si quiero hacer esto? Y si que va a pasar con esto otro? etc". Si se nos ocurren más escenarios para nuestro código, lo que debemos hacer es: escribir una prueba PRIMERO y el código mínimo para pasar esa prueba DESPUÉS ( ¿por eso se llama dirigido por pruebas no? )

5.- Hacer refactoring.

A veces este punto no aplica, como en este caso así que seguimos.

6.- Repetir.

Así que vamos a la segunda prueba ¿Cual podría ser?, Pos claaaro!!!, probar con "falso" no?

• Agregar prueba

   

• Ver si falla

Esta vez espero que falle, por que no he hecho nada para que funcione.

Estatus 2 pruebas fallando 1

• Escribir el código para que pase

Aquí viene toda la magia ( que no es mucha ) ¿Qué tengo que escribir para que mi prueba pase? ¿Que tan complejo debe de ser mi código? Respuesta, LO MÁS SIMPLE, POSIBLE, a veces incluso hay que exagerar.

Entonces el código que hace que mi prueba pase es:

• Correr las pruebas

Vemos si es cierto corriendo las pruebas:

Verde de nuevo.

Parece ridículo a esta altura pero estas son las bases de TDD.

• Repetir

Entonces. Tenemos que el ciclo es este:

Vamos a poner más código.

Mi siguiente prueba, será parentesis:

Rojo. ¿Lo mínimo para componerlo? Quitarle los paréntesis. doh!..

Se me ocurre validar también los espacios en blanco. Agrego otro test:

Rojo, de nuevo. ¿Lo mínimo para que funcione? Ignorar los espacios

Verde de nuevo.

Por que no probamos con el operador "y"

Rojo.

¿Que será lo mínimo esta vez? Se me ocurre, que si tiene una "y" , entonces partir por la letra "y" y ver si las partes dan verdadero.

Funcionó:

Acá hay algo importante.

El TDD no es necesariamente algo fácil. Es muy útil, pero se requiere experiencia previa en programación, para ver algunas cosas "a futuro".

Es muy fácil, hacer las pruebas incorrectas, que nos darán la falsa impresión de que estamos avanzando, cuando pudiera ser que estemos dando vueltas en círculo. Lo bueno, es que este tipo de cosas se aprenden con la práctica y al fin del día, las pruebas hablan por si mismas.

Lo peor que nos puede pasar es que tardemos un poco.

En este ejemplo yo hice una funcion recursiva para evaluar las partes. Claro, tengo que saber que es una funcion recursiva y cuando aplicarla etc.

Seguimos. ¿Cual podría ser mi siguiente prueba? Podría ser probar usando paréntesis. Según yo esto debería de jalar bien:

Oops, me dio rojo.. mmmhh a veces no es tán fácil saber que está pasando. Sobre todo porque el mensaje de eror es un stacktrace como este:

No dice mucho más de lo que ya sé.

Lo que yo hago ( y quizá sea una mala práctica ) es poner logs para entender que es lo que sucede ( aunque desafía el propósito, pues el TDD sirve precisamente para deshacerse de los logs para probar ) Cuando entiendo que pasa se los quito.

En este caso mi prueba dice: "verdadero )" y eso hace que falle. Revisando mi código dice

Es decir, si empieza y termina con "(" y con ")", entonces quitaselo, pero no dice que hacer si solo empieza o solo termina con paréntesis. Una vez detectado el problema, lo podemos arreglar y continuar:

Verde de nuevo:

Y quitamos el log.

Ya podemos seguir con el "o" ( or lógico )

Lo arreglamos... mhh creo que no es tán sencillo por que yo tengo estoy separando por cada "y" que me encuentro. Por que no mejor, evaluo la primera parte y dejo que el resto se evalue recursivamente:

Ok, creo que está mejor, ahora ver si sirve para el or:

Funcionó. Aún le hace falta mucho más código y pruebas. Por ejemplo, que evalué correctamente la precedencia de los paréntesis, o que pueda combinar varias expresiones anidadas o que soporte otro operador como el xor. En fin, este pretendía ser un ejemplo breve de como hacer el TDD, aunque por lo visto no fue tan breve.

Lo realmente interesante es el efecto que tiene esta practica en la calidad del software a la larga, sobre todo en proyectos grandes. Vi hace poco un dashboard de Google Chrome donde venía un estatus de todos los builds automatizados que corren diariamente. Todo esto es posible gracias a que gran parte del código de Google Chrome se hace con TDD.

Ahi va el link:

Espero que esto les resulte útil.