En este capítulo , desarrollaremos más comprensión de lo que es TDD y el secreto ( y no tan secretos) de sus ingredientes que lo hacen funcionar. Realizaremos los pasos siguientes después de haber escrito código de prueba. aprendiendo en el transcurso. Escribiremos pequeñas pruebas, eliminando los comportamientos paso a paso y refactorizando nuestro código sin piedad.
Agregaremos y eliminaremos códigos, Modificando el código de manera que podamos quitar código. A lo largo del camino, vamos a introducir a aplicaciones robustas y capaz de un motor de plantillas, incluyendo algunas funciones de control de excepciones para seguir una conducta al camino "feliz". Se discute cómo amenudo hay dos caminos posibles, anchura y profundidad.
Agregaremos y eliminaremos códigos, Modificando el código de manera que podamos quitar código. A lo largo del camino, vamos a introducir a aplicaciones robustas y capaz de un motor de plantillas, incluyendo algunas funciones de control de excepciones para seguir una conducta al camino "feliz". Se discute cómo amenudo hay dos caminos posibles, anchura y profundidad.
Usted deberá tener una comprensión mucho mejor de cómo funciona TDD en la práctica y qué tipo de trucos seguiremos con el fin de movernos con más rapidez hacia el objetivo de un sistema de funciones completas.
Comenzaremos con el desarrollo de software real que utiliza TDD. Vamos a desarrollar un motor de template que pueden convertir las plantillas que contienen las variables y que son completadas en forma de lista en tiempo de ejecución Considerando que el primer paso en TDD es escribir un defecto de prueba , tenemos que averiguar la conducta deseada que nos gustaría probar.Tendremos una charla rápida sobre cómo llegar de un requisitos abstractos a las pruebas concretas.
2.1 Desde los requerimientos a los test
Imagine que usted tiene que implementar un subsistema para la colaboración de una corporación de software y en responsable de proveer plantillas de correos funcionales para los asistente de CEO para que puedan enviar todo tipo importante de documentos , personalizados con sólo dar doble click en el mouse.Qué pruebas realizaría en el desarrollo de dicho subsistema? Vas a conocer esta respuesta al leer este capítulo , cómo con cualquier sistema descomponeremos los requisitos en algo más pequeño y más concreto.
2.1.1 Descomposición de requerimientos.
Teniendo todos los requisitos previstos para el subsistema, tenemos que hacer una lista de lo que necesitamos hacer, denominadas tareas, ahora borra en forma momentánea las tareas de tu cabeza y hagamos todo de nuevo. Recortemos los requisitos en un conjunto de pruebas. ¿Puedes pensar en estas pruebas? a puesto que si ha pensado en un grupo de pruebas.
Una plantilla de correo sin variables de entrada es enviado. El marcado de posición para el nombre destinatario en un saludos reemplazaría por cada nombre de los destinatarios. Luego usted tendrá un montón de pruebas, que en conjunto comprobaría una parte del conjunto. Con el tiempo, tendrá cubiertos las expectativas del comportamiento del producto.
Para aclarar la diferencia entre tareas y test, la figura 2.1 contrasta algunas de las descomposiciones posibles de la plantilla de correo en tareas y test, respectivamente. Descompondremos las tareas (columna izquierda) donde lleva los elementos que hacen representativos el software producido. La columna de la derecha es la columna de pruebas, que representa las capacidades del software.
Las tareas sólo nos dan una idea de lo que debemos hacer. Veremos más ejemplos de los requisitos en descomposición en las pruebas en lugar de tareas.
Las tareas sólo nos dan una idea de lo que debemos hacer. Veremos más ejemplos de los requisitos en descomposición en las pruebas en lugar de tareas.2.1.2 ¿Qué buenas pruebas podemos hacer?
Hay algunas pautas que podemos utilizar para determinar si estamos escribiendo buenas pruebas. Hay un montón de reglas para la ejecución técnica de una unidad de prueba. Desde la perspectiva de la descomposición de requisitos en las pruebas, existen dos propiedades importantes que se identifican:
- Una buena prueba es atómica.
- Una buena prueba es aislada
Estas propiedades nos quiere decir que una buena prueba debe ser una prueba pequeña, focalizada, atómica, que separa la conducta deseada y que la prueba debe ser aislada de otras pruebas.
2.1.3 Trabajando a partir de una lista de pruebas
Procedemos a generar una lista de pruebas, de las que eligimos una , las más representativa en avance con el menor esfuerzo. Luego empezaremos por escribir el código de prueba. Vamos a ir tan lejos como para compilar y ejecutar la prueba antes de pensar en escribir el código de producción.
2.1.4 Programación por intento
Cuando se está escribiendo pruebas antes de que el código pase a producción, se enfrentan a un dilema: ¿Cómo probar algo que no existen sin romper las normas de ensayo de sesiones?. La respuesta es muy simple, imaginar que el código que se está probando, existe!!.
¿Cómo eso es posible? ¿Qué se supone que debemos pensar? Nos imaginamos una forma ideal en el código de producción desde el punto de vista de esta prueba en particular. ¿No es hacer trampa?. Si, lo estamos engañando, nos encanta¡ Usted escribe las pruebas suponiendo que el código de producción es tan fácil de usar como lo que nos imaginamos.
A esto se le denomina Programación por intento. Programación por intento es el concepto de la escritura de código, cómo si existiera otro trozo de código.
Ahora sabemos que debemos dividir nuestras necesidades en pequeñas pruebas centralizadas en lugar de tareas, ahora podemos entender que la lista de pruebas es una lista de programación por intento, este el momento de desarrollar una plantilla de tipos de pruebas con motores de sesiones.
2.2 Eligiendo la primera prueba.
Lo prometido, desarrollaremos un motor de plantillas basado en pruebas. Nos concentraremos entonces, en la lógica de negocio para el motor de las plantillas y no preocuparnos de todo el sistema.
TIP: En este punto, se recomienda un IDE favorito para desarrollar el motor de plantillas paso a paso.
El motor de plantillas tiene que ser capaz de leer en una plantilla, es decir, ser capaz de leer un texto estático con un número arbitrario de marcadores de variables de posición mezcladas con variables marcadas con una sintáxis específicas. Pero primero, debemos de hacer la plantilla, donde hay que dar valores para la variable nombre.
Lo primero que tenemos que hacer es porcesar la descripción del motor de la plantilla, en una lista inicial de las pruebas, a continuación , elija uno de ellos que deba aplicarse.
2.2.1 Creando una lista de pruebas
Antes que todo, debemos plantear el conjunto de requisitos para el subsistema de la plantilla de correo
* El sistema reemplaza los marcadores de posición variable como $ (firstname) y $ () apellido a partir de una plantilla obtenidad con el tiempo de ejecución.
* El sistema intenta enviar una plantillas con algunas variables no pobladas (variables en null), esto generará un error.
* El sistema ignora los valores de las variables que no se encuentran el la plantilla (validación de entradas o en los campos template).
* El sistema es compatible con el carácter completo Latin-1 establecido en las plantillas.
* El sistema es compatible con el caráter completo Latin-1 situado en valores de las variables.
* Y así sucesivamente.....
He aquí un intento de convertir a la plantilla de correo, los requisitos del subsistema de pruebas adecuadas:
* La evaluación del template "Hola, $ (nombre)" con el valor "lector" de la variable "El nombre de" resultados en la cadena "Hola, lector".
* La evaluación del template "$() saludo, $(nombre)" "Hola" y "El lector" respectivamente, los resultados en la cadena "¡Hola! Reader".
* La evaluación del template "Hola, $(nombre)" sin valor para la variable "nombre" no indica que debemos emplear un MissingValueError.
* La evaluación del template "Hola, $(nombre)" con valores "Hola" y "Reader", resulta en las variables "DoesNoExit" y "nombre, respectivamente, en la cadena "Hola, lector".
* Y así sucesivamente...(podríamos , por ejemplo, incluir algunos ejemplos concretos que serviría como prueba de que el sistema se ocupa de caracteres Latin-1)
Observa la diferencia? Las necesidades se han transformado claramente en un grado más concreto, más ejecutables. Con estas pruebas no hay necesidad de preguntarse por ejemplo, lo que significa "elevar un error" y suponiendo que significa una excepción ¿qué tipo de excepción que debería ser y lo que el mensaje de excepción debería decir?. Las pruebas nos dicen qué excepción MissingValueError deberíamos lanzar para un error específico.
Con este tipo de prueba, estamos en condiciones de producir respuestas binarias para la pregunta "estoy listo?". La lista de prueba es un documento de trabajo donde añadimos nuevas pruebas sobre la marcha.
Tenemos una lista de pruebas que nos dicen exáctamente cuando los requsitos se han cumplido. A continuación , empezaremos a trabajar con la lista haciendolos correr uno por uno.
2.2.2 Escribiendo el primer defecto de prueba
Tomemos la primera prueba de la lista y ver cómo podemos escribir el test antes del código.
Esta es nuestra prueba nuevamente:
La evaluación del template, "Hola, $(name)" el valor "lector" de la variable "El nombre de" resultados en la cadena "Hola, lector"
Nota: En este usaremos el IDE para escribir algo de código. Usaremos JUnit 4, la última versión de framework de pruebas unitarias para JAVA (htpp://www.junit.org). Si no estas familiarizado con JUnit leer el apéndice A para una breve introducción. El objetivo es ver la programación por la intención en la acción.
Porque vamos a poner en práctica la primera prueba, vamos a emprezar por dar un nombre a nuestra clase de prueba , en el listado 2.1
2.2 Eligiendo la primera prueba.
Lo prometido, desarrollaremos un motor de plantillas basado en pruebas. Nos concentraremos entonces, en la lógica de negocio para el motor de las plantillas y no preocuparnos de todo el sistema.
TIP: En este punto, se recomienda un IDE favorito para desarrollar el motor de plantillas paso a paso.
El motor de plantillas tiene que ser capaz de leer en una plantilla, es decir, ser capaz de leer un texto estático con un número arbitrario de marcadores de variables de posición mezcladas con variables marcadas con una sintáxis específicas. Pero primero, debemos de hacer la plantilla, donde hay que dar valores para la variable nombre.
Lo primero que tenemos que hacer es porcesar la descripción del motor de la plantilla, en una lista inicial de las pruebas, a continuación , elija uno de ellos que deba aplicarse.
2.2.1 Creando una lista de pruebas
Antes que todo, debemos plantear el conjunto de requisitos para el subsistema de la plantilla de correo
* El sistema reemplaza los marcadores de posición variable como $ (firstname) y $ () apellido a partir de una plantilla obtenidad con el tiempo de ejecución.
* El sistema intenta enviar una plantillas con algunas variables no pobladas (variables en null), esto generará un error.
* El sistema ignora los valores de las variables que no se encuentran el la plantilla (validación de entradas o en los campos template).
* El sistema es compatible con el carácter completo Latin-1 establecido en las plantillas.
* El sistema es compatible con el caráter completo Latin-1 situado en valores de las variables.
* Y así sucesivamente.....
He aquí un intento de convertir a la plantilla de correo, los requisitos del subsistema de pruebas adecuadas:
* La evaluación del template "Hola, $ (nombre)" con el valor "lector" de la variable "El nombre de" resultados en la cadena "Hola, lector".
* La evaluación del template "$() saludo, $(nombre)" "Hola" y "El lector" respectivamente, los resultados en la cadena "¡Hola! Reader".
* La evaluación del template "Hola, $(nombre)" sin valor para la variable "nombre" no indica que debemos emplear un MissingValueError.
* La evaluación del template "Hola, $(nombre)" con valores "Hola" y "Reader", resulta en las variables "DoesNoExit" y "nombre, respectivamente, en la cadena "Hola, lector".
* Y así sucesivamente...(podríamos , por ejemplo, incluir algunos ejemplos concretos que serviría como prueba de que el sistema se ocupa de caracteres Latin-1)
Observa la diferencia? Las necesidades se han transformado claramente en un grado más concreto, más ejecutables. Con estas pruebas no hay necesidad de preguntarse por ejemplo, lo que significa "elevar un error" y suponiendo que significa una excepción ¿qué tipo de excepción que debería ser y lo que el mensaje de excepción debería decir?. Las pruebas nos dicen qué excepción MissingValueError deberíamos lanzar para un error específico.
Con este tipo de prueba, estamos en condiciones de producir respuestas binarias para la pregunta "estoy listo?". La lista de prueba es un documento de trabajo donde añadimos nuevas pruebas sobre la marcha.
Tenemos una lista de pruebas que nos dicen exáctamente cuando los requsitos se han cumplido. A continuación , empezaremos a trabajar con la lista haciendolos correr uno por uno.
2.2.2 Escribiendo el primer defecto de prueba
Tomemos la primera prueba de la lista y ver cómo podemos escribir el test antes del código.
Esta es nuestra prueba nuevamente:
La evaluación del template, "Hola, $(name)" el valor "lector" de la variable "El nombre de" resultados en la cadena "Hola, lector"
Nota: En este usaremos el IDE para escribir algo de código. Usaremos JUnit 4, la última versión de framework de pruebas unitarias para JAVA (htpp://www.junit.org). Si no estas familiarizado con JUnit leer el apéndice A para una breve introducción. El objetivo es ver la programación por la intención en la acción.
Porque vamos a poner en práctica la primera prueba, vamos a emprezar por dar un nombre a nuestra clase de prueba , en el listado 2.1
El código del listado 2.3 es lo que podríamos escribir para una prueba, suponiendo que la aplicación está ahí (aunque no lo es) la libertad para diseñar la plantilla en función de una manera más fácil de usar.
En el método de ensayo del listado 2.3, crea en primer lugar un objeto que al pasar por la plantilla de texto como un argumento de texto de constructor. Luego se establece un valor para la variable "nombre" y finalmente, invoca un método denominado evaluar, que confirma los valores que se le estan pasando al constructor.La salida resultante es a la altura de las expectativas.
¿Cómo se siente? ¿Es así como le gustaría que el sistema de plantillas trabajé? Vamos a proceder y ver cómo podemos hacer que el compilador potencie el código.
Haciendo una compilación con éxito
El compilador está dispuesto a recordarnos que, a pesar de nuestras intensiones, la plantilla de clase no existe. Se debe destacar que los métodos establecidos y evaluar no existen asi que tendremos que añadirlos. Terminamos con el esqueleto de una clase, en el listado 2.4.
Finalmente compilamos el código. Que viene luego? , ejecutamos el test.
Ejecutamos el test
Cuando ejecutamos nuestro código recién escrito, se produce un error- no es de extrañarnos - porque no hemos añadido aún los métodos.
Ejecutamos la prueba para obtener la salida como se muestra en la figura 2.2, obteniendo un mull cuando se esperaba una cadena "Hola, lector"
Estamos en la fase roja del ciclo TDD, lo que significa que hemos escrito y ejecutado una prueba que está fallando, y nuestro IDE indica una barra roja en su compilación. Ya hemos escrito una prueba y tenemos un esqueleto del código de producción que pone a prueba nuestra prueba. Por ahora, todo lo que queda es implementar la plantilla de clase para que al compilarlo veamos una barra verde en nuestro IDE.
No hay comentarios:
Publicar un comentario