Capítulo 2.4.1 Refactorizando el código potencialmente.

2.4.1 Refactorizando el código potencialmente.

En primer lugar, todas nuestras pruebas utilizan objeto del template, por lo tanto deberíamos declarar la instancia una vez y no varias veces como se ha visto. En segundo lugar, estamos llamando al método a evaluar varias veces como un argumento. En tercer lugar, estamos instanciando la clase del template con la misma plantilla de texto en dos lugares. Esa es la duplicación y , probablemente se deba quitar.

Sin embargo, una de las pruebas está utilizando un template diferente de texto. ¿Debemos utilizar dos variables ejemplo, uno para cada pplantilla de texto? Si es así, quizas sea conveniente dividir la clase en dos para hacer frente dos partidos.

Nota: Un accesorio es un conjunto de variables de instancia.

Existe otra alternativa para la división de la clase con TestTaemplate. Vamos a ver la otra alternativa de refactorización.

2.4.2 Eliminación de una prueba redundante

Hay un tipo más fundamental de la actual duplicación de nuestro código de prueba oneVariable, differentTemplate y multipleVariables. Si lo pensamos el último método abarca los anteriores. El primero tambien abarca todas las combinaciones por lo tanto podemos deshacernos de la versión dejando una sola variable,. También se suma una nueva prueba para verificar que podemos establecer un nuevo valor para volver evaluar el template. Podemos ampliar a una variable desconocido VariabeAreIgnored utilizando la misma plantilla de texto como multipleVariables. Y vamos a ver lo que el código de prueba se muestra en la lista refactorizada 2.13.

Como se puede ver, hemos sido capaces de moldear nuestras pruebas a utilizar en un sólo modelo de texto configurado, dejando a los 4 métodos de ensayo. Ahora podemos ver el manejo de errores.

2.5 Agrengando un poco de control de errores

Este es el momento de añadir una nueva prueba.

2.5.1 Esperando una excepción

¿Cómo escribir una prueba unitaria que lanze una excepción? Con el constructor trycatch, por supuesto, sólo que esta vez , el código de una excepción es una buen caso- el comportamiento esperado. Como se muestra en la lista 2.14 , es un patron común para la excepción del test - ejecutado con JUnit

Nota : Tenga en cuenta la llamada al método después de dejar evaluar correctamente. Con ese llamado a org.junit.Assert#fail, decimos básicamente, "si llegamos hasta aca, es que algo salío mal" y el método no falla en la prueba. Sin embargo llamamos al método "evaluate". La hacer click en aceptar, tenemos una prueba que está fallando, aunque antes ni siquiera compilaba, pero añadiendo una clase MissingValueException vacío hace que desaparesca
Veamos la lista 2.15 para ver la mejora del código anterior.
2.5.2 Refactorizando pequeños métodos

Existen diferencias en el tamaño de los métodos, clases , etc. En el listado 2.16 muestra una versión de refactorización del método "evaluate"2.5.3 Mantener el equilibrio en los métodos

Una característica de un método es la coherencia de abstracción del código. Veamos el siguiente ejemplo.El método se evalúa haciendo dos cosas: sustituir las variables con valores y comprobar los valores que faltan en un nivel diferente de abstracción. La iteración "for" es claramente más complicado que la llamada al método checkforMissingValues. A menudo es fácil agregar pedacitos de funcionalidad pegando en línea a un método ya existente, pero sin perder de vista la incosistencia en nivel de abstracción, el código es un poco ininteligible.

Veamos en la lista 2.17 una simple aplicación de la refactorización del "método de extracción".
Ejecutamos nuesttos casos de pruebas, y nos damos cuenta que no se obtubo ningún problema con la refactorización. Hacer este tipo de ediciones en el código de trabajo sería un gran esfuerzo, sino tuvieramos la batería de casos de pruebas en nuestra espalda. Ahora falta un mensaje significativo para la excepción.

2.5.4 Detalles para una excepción.

Mientras escribe la prueba para el valor que falta, sólo se alcanzó a llamar una vez a la excepción MissingValueExcepction. O a veces usted a visto varias veces un mensaje que ni siquiera tiene un sentido informativo con sentido. Quizas lo que falte es agregar un valor al mensaje de la excepción. Observe el listado 2.18.Como de costumbre, editar y ejecutar un caso de prueba sólo toma unos minutos. Esta vez, usamos una API java.util.regex un poco diferente cone l fin de extraer el resultado que coincide con el patrón de la variable. Se explica mejor en la siguiente fracción de código.

Como de costumbre, la edición para la toma de un pase de prueba es una cuestión de un par de minutos.

Esta vez, tenemos que usar el API java.util.regex un poco diferente con el fin de extraer la parte del resultado renderizado que coincide con un patrón variable. Tal vez un fragmento de código que podría explicar mejor:

2.6 Cabos sueltos en la lista de casos

Hemos implementados todos los casos de prueba que proposupimos en el principio. Sinembargo, descubrirá algunos problemas con la implementación actual. Primero, no maneja valores de variables tales como delimitadores como "$("y")". Una de las pruebas restantes es el rendimiento a nuestra lista de casos.

• Evaluar el template con los siguientes variable "$(un), $ (dos), () tres" con los valores "1", "$(foo)", y "3", respectivamente, y comprobar que el template hace que la ejecución resulte como "1,$(Foo),3".

• Compruebe que un template de 100 palabras y 20 variables con valores 15 caracteres cada uno se evalúa en 200 milisegundos o menos.

2.6.1 Pruebas de rendimiento

Para tener una idea de si nuestra ejecución del template es correcta en cualquier performace, vamos a añadir una prueba rápida para evaluar el desempeño y asi ver si estamos cerca de un plazo de ejecución razonable. Esto se plantea en el listado 2.19.

Parece que nuestra aplicación de template no pasan la prueba de rendimiento para que se ejecute en 100 milisegundos para una template de 100 palabras con 20 variables. Sin embargo es bueno saber que se está gastando presuepuesto en el rendimiento. Ahora que sabemos que lo que está en su lugar , sabremos de inmediato cuando un cambio haga más lenta la ejecución.

2.6.2 Acercándonos al final del diseño.

En cuanto a la prueba restantes para los valores de las variables "$("y")", comienzan a ser más difícil ya que el trabajo de búsqueda y reemplazo no es tan simple de realizar. Además , no podemos confiar que nuestro método de detecciñon de variables no definidas mediante la búsqueda "${ }" sea un buen resultado.

Antes de seguir adelante, vamos a para toda estas especulaciones y escribiremos una prueba que denuestra si nuestras suposiciones sobre el comportamiento alctual del código es correcta. Agregar el siguiente caso de prueba en la clase TestTemplate, como se muestra a continuación:

La ejecución de nuestra prueba nos dice que ciertamente tenemos un problema. Esta prueba está arrojando un IllegalArgumentException desde el código de expresiones regulares. Es momento de volver fuera de la prueba, levantar el bloc de notas y dibujar un poco. En su lugar, vamos a resumir el capítulo hasta este momento, para comenzar con el siguiente capítulo.

2.7 Resúmen

El desarrollo basado en pruebas es una técnica poderosa que nos permite escribir mejor el código de un software y su ejecución se a más rápida. Lo hace centrádose en las necesidades del momento, haciendo que el trabajo presente pequeñas muestras, finalmente limpiar cualquier código que ensucie la funcionalidad, de mantenenimiento efectivo la salud de la base de código. En este ciclo primero es la escritura de la prueba, para que pueda ser ejecutado sin problemas, finalmente se realiza la refactorización del diseño que permite hacer un uso intensivo de la programación en la redacción de la prueba como si la prueba real exista y con una herramienta para creación de útiles diseño.

En este capítulo , hemos visto TDD en acción y no hemos dado cuenta que nuestro diseño actual del template no termina con un buena ejecución. Nos propusimos escribir un motor de template basado en una pequela lista de casos que apuntan al comportamiento esperado por el motor y seguimos un set de pruebas de código factorizado (rojo-verde-verde). Una vez que el código cumpla la mayoría de nuestro requisitos somos capaces de tomar decisiones más rápida en el avence de las pruebas y no tenemos miedo a refactorizar.

Ahora , vamos a voltear la página para el siguiente capítulo y ver cómo podemos superar las cuestiones pentiendes y concluir el motor de template funcionalmente, quedando una bonita pieza de producto.