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 veces que los test necesitarán de recursos externos que estarán definidos en «setUp()». Si los test tienen que ser independientes los recursos tienen liberarse en algún momento antes de terminar el test y para ello se va a utilizar el método «tearDown()».
Sería lógico que según la estrategia de «flags» que estamos utilizado hasta ahora se necesite un otro «flag» para saber si un recurso se ha liberado. El incremento de «flags» empieza a ser un poco molesto y, además, hay otro aspecto que no se está teniendo en cuenta y es el orden de llamada. El método «setUp()» debe llamarse antes de «tearDown».
Si en vez de utilizar los «flags» se utiliza un pequeño «log» al cual se vayan añadiendo textos con el nombre de los métodos que se van ejecutando podríamos verificar qué métodos se han llamado y en qué orden.
Para realizar la refactorización primero implementamos la variable «log» y en añadimos al log el texto «setUp».
Refactorizamos el test «testSepUp()» para verificar que el texto que hay en el log coincide con la cadena «setUp ».
Ejecutamos «main» y se ejecuta correctamente. Ahora se puede borrar el flag «wasSetUp» de la clase «WasRun».
Se vuelven a ejecutar «main» y funciona todo correctamente.
El siguiente paso es refactorizar para cambiar el método de prueba «testSetUp()» y que utilice el log. Como el método «setUp()» se ejecuta primero el resultado del log tiene que ser «setUp testMethod ».
Ejecutamos «main» y, efectivamente, falla el test. Ahora refactorizamos para añadir la cadena «testMethod » al «log» cuando se ejecuta un test.
Ejecutamos «main» y Upss! Con este cambio se rompe el método de prueba «testSetUp» ya que el valor del log es «setUp testMethod » y no «setUp ». Así que cambiamos el texto por el resultado esperado.
Ejecutamos «main» y no se producen errores.
Este método de prueba «testSetUp()» incluye tanto la verificación de si se ha ejecutado «wasRun» tanto com si se ha ejecutado el «setUp». Por esta razón, se pueden refactorizar los dos métodos de prueba de manera que «testSepUp» se renombra a «testTemplateMethod()» y «testRunning()» ya no es necesario.
Se puede apreciar que la instancia «WasRun» sólo se está utilizando en el método «testTemplateMethod» por lo que es una buena práctica refactorizarla e incluirla en el único método que la utiliza.
Kent Beck comenta que hacer una refactorización basada en un par de usos para más tarde deshacerla es una práctica común. Hay personas que prefieren esperar hasta que tienen tres o cuatro usos antes de refactorizar por no deshacer trabajo pero Kent prefiere gastar ese tiempo en el diseño y hacer las refactorizaciones en vez de preocuparse si tendrá o no que deshacer la refactorización en un paso posterior.
Una vez hecha la refactorización es tiempo de implementar «tearDown()». Dado que tenemos un método de prueba que está basado en la cadena del log, vamos a modificar este para incluir la cadena «tearDown ».
Ejecutamos «main» y tenemos un error. Estamos en «rojo» y tenemos que desarrollar la funcionalidad para volver a «verde».
Como queremo que «tearDown()» se ejecute después de la llamada al método de prueba lo más lógico es hacer la llamada después de que el método de prueba se haya ejecutado. Para ello creamos un método «tearDown()» y hacemos la llamada dentro del método «run()».
Aunque hayamos definido el método «tearDown()», es la clase «WasRun» quien lo sobrecarga
La ejecución ya no da error y no hace falta refactorizar ya que el código funciona y es sencillo.
En este capítulo:
- Se ha cambiado la estrategia de testeo de flags a un log.
- Se ha implementado «tearDown» usando el log.
Podemos tachar la tarea «tearDown» de la lista:
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.
No hay comentarios:
Publicar un comentario