Capítulo 25: How Suite It Is - TDD By Example

Es el momento de abordar la tarea de ejecutar múltiples pruebas sin tener que ejecutarlos de una forma tan poco elegante como se había estado haciendo hasta ahora.

El objetivo es crear una batería de pruebas que pueda ejecutar las distintas pruebas de forma aislada y devolver el resultado de las mismas. Otra razón para implementar «TestSuite» es que nos da un ejemplo de «Composite», esto es que podamos ejecutar una prueba o un grupo de ellas de la misma manera.

Así que, como se hace en TDD comenzamos creando una prueba para después abordar su implementación.

Añadimos la prueba en «main».

Lo ejecutamos y da un error ya que no encuentra la clase «TestSuite». Así que implementamos la clase. En este caso, las pruebas deberían compartir un objeto «TestResult» por lo que lo definimos en el método «run» para que lo utilice cada prueba.

Sin embargo, el patrón «composite» establece que la colección de pruebas tiene que responder los mismos mensajes que una prueba. Así que, si añadimos un parámetro al método «run()» de los «TestCase» tenemos que añadir el mismo parámetro al método «run()» de «TestSuite». Así que se va a utilizar el patrón «Collecting Parameter» y se crearán los «TestResult» en las clases donde se hace la llamada.

Esta solución tiene la ventaja de que el método «run()» no devuelve un resultado sino que altera el estado del objeto «result». Modificamos las clases «TestSuite» para que acepte el parámetro.

Modificamos la clase «TestCase» para pasar el parámetro.

Y ahora podemos modificar la ejecución de las pruebas en «main».

Si ejecutamos «main», podemos observar que fallan el resto de pruebas de «TestCaseTest» ya que no hemos modificado estas para que utilicen el parámetro en su método «result()». Así que pasamos a modificarlas.

Si volvemos a ejecutar «main» no se produce ningún error. Volvemos a estar en «verde».

Podemos darnos cuenta de que «TestResult» se crea en todos los métodos de prueba por lo que podríamos incluir este en el método «setUp()» aunque se añada un poco de complejidad a la hora de leer.

En este capítulo se ha visto:

• Escribir un método de prueba para «TestSuite». 
• Escribir parte de la implementación sin hacer funcionar el método de prueba con una implementación falsa («fake implementation»). 
• Modificar la interfaz del método «run()» para que la prueba y el conjunto de las pruebas funcione de manera idéntica. 
• Se ha refactorizado la creación de la instancia de «TestResult» en el método «setUp()».