jueves, 21 de junio de 2018

Capítulo 24: Dealing with Faulure - TDD By Example

En este capítulo se continúa con la tarea de informar las pruebas que han fallado:
  • 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.
Para abordar esta tarea se va a crear un método de prueba que asegure que se imprime el resultado correcto cuando un método de prueba falla. La clase «TestResult» es la responsable del resultado por lo que se va a implementar un método «testFailed()», de igual manera que «testStarted()», para indicar que la prueba en ejecución ha fallado. El método de prueba sería el siguiente:

Añadimos a «main» su ejecución.

Si lo ejecutamos falla ya que el método «testFailed()» no está implementado. Creamos el método e implementamos el contador «errorCount» como un atributo. El contador se tiene que inicializar a 0.

Si ejecutamos «main» se producirá un error ya que la cadena que devuelve será “1 run, 0 failed” debido a que el método «summary()» tiene una constante.

Si ejecutamos «main» y los método de prueba vuelven a pasar. Estamos en «verde».
Los métodos «testStarted()» y «testFailed()» modifican el texto que va a devolver el método «summary()» dependiendo de si el test empieza o ha fallado. En los casos en los que se ejecute más de un test el uso de estos dos métodos va a modificará cuantos test se han ejecutado y cuántos han fallado.
¿Cuando hay que ejecutar el método «testFailed()»? Cuando el método que se está probando lance una excepción por lo que habrá que capturar si se lanza alguna excepción cuando se ejecuta el método que se está probando.

El problema de esta estrategia es que si hay una excepción durante «setUp()» esta no se captura. Esto se anota para hacer el test más adelante en la lista de tareas:
  • 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.
  • Capturar e informar de los errores de «setUp»
En este capítulo se ha visto:
  • Cómo crear un test para un caso particular.
  • Cómo implementar la solución para un caso general con el uso de variables.
  • Anotar el control de errores en el método «setUp()» para hacerlo en una fase posterior y no abordarlo inmediatamente.

No hay comentarios:

Publicar un comentario