Capítulo 23: Counting - TDD By Example

Según la lista de tareas la siguiente sería ejecutar «tearDown» incluso si el método falla:

• Ejecutar el método de prueba.
• Ejecutar un «setUp» primero. 
• Ejecutar «tearDown» después. 
• Ejecutar «tearDown» incluso si el método falla. 
• Ejecutar multiples test. 
• Informar de los resultados.
  

Hay que asegurar que «tearDown()» se ejecuta independientemente de si hay algún tipo de excepción durante la prueba lo que implica el control de las excepciones que puedan ocurrir.  Controlar las excepciones también implica que, en el caso de producirse un error, la excepción se capturará y no se informará de ella.

En general, el orden de los test es importante y se deberían elegir aquellos test que se tenga la confianza de poder hacerlos funcionar. Aunque se darán casos en los que se resolverá un test pero el siguiente se complicará por lo que habrá que considerar hacer una copia de seguridad y volver un paso atrás. Así que, en este caso, se va a realizar la tarea de informar de los resultados.

Cuando se ejecutan todos los test nos gustaría tener un informe con el número de test que se han ejecutado, los que han fallado y la razón por la que han fallado. Aunque esto sería el objetivo final el primer caso sería ejecutar un simple test que no falle.

Para implementar ese informe se va crear un objeto «TestResult» que almacene el resultado de ejecutar el test y este informe será devuelto por el test cuando se ejecute.

Si ejecutamos el test falla. Ya tenemos el test para empezar a desarrollar. Así que empezamos con la implementación más sencilla que es crear la clase y devolver en el método «summary()» la cadena esperada.

Se devuelve una instancia de la clase «TestResult» en el método «run()» de «TestCase».

Si ejecutamos los test estos vuelven a funcionar. Estamos en verde. Toca la fase de refactorización. Se procede a cambiar la implementación de «summary()» en pequeños pasos. Primero se cambian el número de test  que se han ejecutado para que se coja desde una variable.

Los test funcionan correctamente. Seguimos refactorizando de lo particular a lo general. Los test no deberían empezar en 1 si no en 0. Entonces tendremos que inicializar desde 0 la variable e incrementarla desde un método «testStarted()» a la cual se hará una llamada cada vez que se ejecute un test.

¿Dónde se tiene que hacer la llamada a «testStarted()»? La llamada se tiene que hacer antes de la llamada «setUp()» en el método «run()».

Se podría cambiar la constante 0 del número de test fallados para que fuera una variable de la misma manera que se ha cambiado «runCount()». Sin embargo, como no es necesario para el test no se hace. Lo que sí se hace en estos casos es crear un nuevo test para demandar el cambio. Para ello creamos un nuevo método de prueba «testFailedResult()».

Creamos un nuevo test en «main» y lo ejecutamos.
Si ejecutamos este test efectivamente falla por no estar implementado el método «testBrokenMethod()». Así que hacemos la implementación y lanzamos una excepción.

Al ejecutar nuevamente los test tenemos un error con la excepción la excepción que acabamos de lanzar la cual no hemos controlado. Aunque nos gustaría controlar la excepción lo dejamos sin implementar..

• Ejecutar el método de prueba. 
• Ejecutar un «setUp» primero. 
• Ejecutar «tearDown» después. 
• Ejecutar «tearDown» incluso si el método falla. 
• Ejecutar multiples test. 
• Informar de los resultados. 
• Informar de las pruebas que han fallado.

En este capítulo se ha visto:

• Escribir una implementación simulada (fake implementation) para ir refactorizando hacia el mundo real reemplazando las constantes con variables. 
• Se ha escrito otro test. 
• Cuando un test falla se ha escrito otro test, a un escala más pequeña, para dar soporte haciendo que los test que fallan funcionen.