Tema Tests Java PDF

LIDIA
Laboratorio de Investigacin y
desarrollo en Inteligencia Artificial
Departamento de Computacin
Universidade da Corua, Espaa
Principios de Anlisis Informtico
Tema 7: Fase de Transicin
Eduardo Mosqueira Rey
2
Eduardo Mosqueira Rey Departamento de Computacin Universidade da Corua
ndice
1. Introduccin
2. Tipos de tests
3. Refactorizacin
3
Introduccin
Uno de los principales esfuerzos en la fase de
transicin es el proceso de prueba de la
herramienta
Aunque siguiendo la filosofa incremental es
necesario tambin hacer pruebas durante el
desarrollo del sistema, sobre todo al final de
cada iteracin
El proceso de prueba consiste en buscar fallos
al programa, conocidos comnmente como
bugs (bichos en ingls)
Pero, por qu se utiliza ese trmino?
4
Introduccin
El 9 de septiembre de 1947
Grace Hopper incluy la
siguiente anotacin en un libro
de log despus de que se
detectara un fallo de
funcionamiento en uno de los
primeros ordenadores
electromecnicos (Mark II)
debido a un bicho que se haba
introducido en un rel
Aunque est demostrado que
el termino ya se usaba con
anterioridad
Esta anotacin est hoy en da
expuesta en el Museo Nacional
de Historia Americana
5
Introduccin
Bugs famosos (ficcin)
En la novela (y el film de 1968) 2001: Una odisea
espacial, el robot HAL trata de eliminar a toda la
tripulacin de su nave debido a lo que, en
posteriores secuelas, descubrimos que es un fallo en
su programacin.
A HAL se le haba ordenado dar toda la informacin
que le pidiera la tripulacin, pero tambin se la haba
ordenado guardar secreto absoluto sobre los
objetivos de la misma
Eliminando a la tripulacin se eliminaba la
contradiccin
Tambin podan haberse acordado de programar la
orden de no matar a la tripulacin
6
Introduccin
Bugs famosos (realidad) Ariane 5
El bug ms caro de la historia fue el del software de
control del cohete espacial Ariane 5
El software convirti un valor flotante de 64 bits en
un entero de 16 bits sin comprobar que se
produjeran desbordamientos
El ordenador central entendi en dato como
verdadero e intent enderezar un supuestamente
desviado cohete en el despegue
La maniobra del cohete fue demasiado brusca y se
destruy a los 37 sg. del despegue
El error no se detect porque por motivos de
eficiencia se eliminaron comprobaciones de error en
tiempo real
7
Introduccin
Bugs famosos (realidad) Mars Climate Orbiter
Sonda espacial de la NASA hacia Marte en 1998
Proyecto valorado en 327 millones de dlares
La sonda trabajaba usando el sistema mtrico
decimal
Los trabajadores en tierra le mandaban datos y
parmetros usando el sistema ingls de medidas
El resultado fue que la sonda no utiliz la trayectoria
correcta para la entrada en el planeta y fue destruida
por la friccin de la atmsfera
8
ndice
2. Tipos de tests
Tests de unidad
Tests de integracin
Tests funcionales
Tests del sistema
9
Tipos de tests
Software
Tests del
sistema
Tests
funcionales
Tests de
integracin
Tests de
unidad
Diseo
Requisitos
funcionales
Otros
requisitos
Inicio
Fin
Pruebas
Informacin
suministrada
Nos aseguramos de que cada mdulo
funciona adecuadamente como una
unidad
Los mdulos ya probados se integran y
se comprueba que el funcionamiento del
programa sigue siendo el correcto
Comprobamos que el software
desarrollado cumple con los requisitos
funcionales definidos en las fases de
anlisis
Comprobamos que el software
desarrollado cumple con otros requisitos:
del usuario, usabilidad, rendimiento, etc.
Es importante destacar que los lmites
entre los distintos tipos de tests son, a
menudo, difusos
10
Tipos de tests
El mbito de los tests de unidad es el
interior de una clase dada
El mbito de los tests de integracin es la
interaccin entre distintos componentes
de una aplicacin. En especial cuando
estos componentes son externos (p. ej.
una base de datos)
El mbito de los tests funcionales es todo
el sistema, tratan de comprobar que se
cumplen los requisitos funcionales
incluidos en la especificacin
11
ndice
Tests de unidad
Desarrollo dirigido por los tests
Herramientas de test
Herramientas de cobertura
12
Tests de unidad
Forma tradicional de actuar con las pruebas de
unidad
Se escriben despus de desarrollar el cdigo que se quiere
probar
Todo lo ms se desarrollan en paralelo si la persona que
desarrollo el cdigo y la persona que lo prueba son la misma
Desarrollo dirigido por los tests (Test-Driven
Development o TDD)
Es una filosofa de desarrollo que se encuadra dentro de las
metodologas giles (y ms concretamente dentro de la eXtreme
Programming)
Bsicamente lo que viene a decir es que las pruebas deben
desarrollarse ANTES que el mdulo que deben probar
13
Tests de unidad
Ventajas del TDD
Los casos de prueba representan los requisitos que esperamos
que cumpla nuestra aplicacin, por lo que al escribirlos tambin
documentamos nuestro sistema
Tener que desarrollar primero el cdigo de prueba significa que
tenemos que ver a nuestro mdulo desde el punto de vista del
cliente que va a usarlo. Esto nos hace centrarnos ms en la
interfaz que debera tener el mdulo y no en su implementacin
(la interfaz debera determinar la implementacin y no al revs)
Es fcil comprobar si el cdigo desarrollado es correcto,
simplemente hay que pasar los casos de prueba. De esta forma
se reducen los tiempos de depuracin de errores
Si automatizamos los casos de prueba es fcil comprobar si
nuestra aplicacin sigue siendo correcta despus de una
refactorizacin (cambios en la estructura interna). Esto nos
permite perder el miedo a realizar modificaciones en el cdigo
14
Tests de unidad
Ciclo de Desarrollo del TDD
Escribir el test
Antes de aadir una nueva funcionalidad se aade la prueba de las misma. Para
escribir la prueba, el desarrollador debe entender claramente las especificaciones y los
requisitos de la nueva funcionalidad (por ejemplo, analizando los casos de uso
definidos para la misma.
Ejecutamos los tests y vemos que el nuevo falla
Comprobamos que el test est escrito correctamente y no da una salida satisfactoria
cuando no debe
Escribir el cdigo:
Escribimos el cdigo de la nueva funcionalidad. El cdigo se disea SOLO para pasar
la prueba, por lo que es aceptable que el cdigo diseado no sea elegante o eficiente.
Esto podr mejorarse posteriormente
Ejecutar las pruebas automatizadas:
El paso siguiente es ejecutar los casos de prueba automatizados y observar si pasan o
fallan. Si pasan, el programador puede garantizar que el cdigo resuelve los casos de
prueba escritos. Si hay fallos, el cdigo no resolvi los casos de prueba.
Refactorizacin:
El paso final es la refactorizacin, donde el cdigo desarrollado se mejora para cumplir
unos estndares de calidad. Despus de cada cambio pueden volverse a ejecutar las
pruebas para probar que el software sigue siendo vlido.
15
Tests de unidad
Limitaciones del TDD
El TDD puede caer en el desarrollo de cdigo correcto (pasa los
tests) pero de baja calidad (se ha evitado o reducido la fase de
refactorizacin)
El TDD slo prueba la funcionalidad que aparece descrita en los
test. Un test incorrecto producir cdigo incorrecto (aunque el
cdigo pase el test)
En definitiva un TDD es tan bueno como lo son los tests, y
escribir buenos tests no siempre es una tarea sencilla.
Por ejemplo, TDD es difcil de usar en situaciones en las cuales
los sistemas tienen entradas y/o salidas complejas (por
ejemplo, GUIs o BDs). En dichos sistemas desarrollar tests de
unidad aislados o realizar refactorizaciones no es sencillo.
16
Tests de unidad
JUnit
JUnit es una librera Java de cdigo abierto que facilita la
realizacin de pruebas de unidad
Bsicamente facilita la construccin de tests y su ejecucin
conjunta
Antes de JUnit las pruebas de unidad se reducan a incluir un
main en cada clase que permitiera probar su ejecucin (poco
cmodo y poco flexible)
NetBeans integra la librera JUnit de forma que es muy sencillo
crear un test para una clase determinada. Adems permite crear
tests en el formato del JUnit v3.8.1, as como en la nueva
versin v4.0 basada en anotaciones. Incluso es posible mezclar
ambos tipos de tests
Mas informacin en: http://junit.org y en
http://junit.netbeans.org/
17
Tests de unidad
Ejemplo
Nos encargan realizar una rutina que calcule si un
ao determinado es bisiesto o no
Especificaciones:
Un ao es bisiesto si es divisible por cuatro lo que provoca
que uno de cada cuatro aos sea bisiesto
Para un mayor ajuste los aos divisibles por 100 no sern
bisiestos, de tal forma que cada 100 aos habr un ao que
debera ser bisiesto y no lo es
Sin embargo si el ao es divisible por 400 s que es bisiesto,
as cada 400 aos habr un ao que no debera ser bisiesto
pero s que lo es
18
Tests de unidad
El primer paso segn el TDD sera
crear el tests. Sin embargo, vamos a
crear una versin trivial del cdigo
para aprovecharnos de las
capacidades de NetBeans de
autogeneracin de tests.
De todas formas el cdigo creado
debe siempre FALLAR el test
19
Tests de unidad
Le decimos a NetBeans que cree un
test JUnit para esta clase.
Tambin le indicamos que vamos a
crear tests siguiendo la versin 4 de
JUnit.
20
Tests de unidad
Podemos elegir sobre que mtodos
queremos hacer las pruebas
(generalmente sern los mtodos pblicos
de la clase)
Los mtodos de inicializacin son
procedimientos que se ejecutan siempre
antes de hacer ningn test (p. ej. leer un
recurso de disco)
Los mtodos de finalizacin realizan la
operacin contraria, se ejecuta al final de
hacer los tests para liberar los recursos
comprometidos
Default Method Bodies crea tests por
defecto cuyo resultado es un fallo
Los tests se generan preferentemente en
un subdirectorio separado de los fuentes
(aunque lgicamente se sitan dentro del
mismo paquete)
21
Tests de unidad
Se aade la librera JUnit a nuestro
proyecto
La clase de test se llama igual que la
clase original pero aadiendo el
sufijo Test, adems se sita en
una jerarqua paralela de directorios
pero dentro del mismo paquete
22
package datetime;
import org.junit.*;
import static org.junit.Assert.*;
public class YearUtilitiesTest
{
public YearUtilitiesTest() {}
@BeforeClass public static void setUpClass() throws Exception {}
@AfterClass public static void tearDownClass() throws Exception {}
@Before public void setUp() {}
@After public void tearDown() {}
/**
* Test of isLeap method, of class YearUtilities.
*/
@Test
public void isLeap()
{
System.out.println("isLeap");
int year = 0;
boolean expResult = false;
boolean result = YearUtilities.isLeap(year);
assertEquals(expResult, result);
// TODO review the generated test code and remove the default call to fail.
fail("The test case is a prototype.");
}
}
Tests de unidad
Importamos las libreras de JUnit 4
Los mtodos marcados con @BeforeClass
son mtodos estticos que se ejecutan
slo una vez antes que cualquiera de los
mtodos de test de la clase. Los mtodos
@AfterClass se ejecutan despus de
forma anloga
Los mtodos marcados con @Before son
mtodos de instancia que se ejecutan
antes que cualquiera de los mtodos de
test de la clase. Los mtodos @After se
ejecutan despus de forma anloga
Los mtodos de test se marcan con la
anotacin @Test. El test utiliza el mtodo
assertEquals para comprobar si el
resultado de llamar al mtodo coincide
con el esperado. Otras posibles funciones
son assertTrue, assertFalse, etc.
El test por defecto desarrollado debe
siempre fallar, para asegurarnos de ello
utilizamos el mtodo fail
23
Tests de unidad
Realizamos ahora la prueba para
determinar si un ao es bisiesto
procurando poner aos que cubran todas
las opciones.
Eliminamos los mtodos Before y After
porque no son necesarios. Before podra
ser til para crear una instancia de la
clase, pero como los mtodos son
estticos no es necesario
Cuanto ms completa sea la prueba ms
fiabilidad habr de que el cdigo
desarrollado sea correcto
24
Tests de unidad
Creamos ahora el cdigo de la clase
Nos habremos equivocado? Estar todo
correcto? no tenemos ms que ejecutar
los tests para comprobarlo
25
Tests de unidad
Podemos ejecutar el test para una clase
en particular o para todo el proyecto
26
Tests de unidad
Los resultados se muestran de forma
grfica. Los tests marcados en verde han
sido superados satisfactoriamente, los
tests marcados en rojo han fallado
27
Tests de unidad
Si modificamos el cdigo para que no
calcule bien los aos divisibles por 400
28
Tests de unidad
Ejecutamos el test y vemos que se
produce un error en la lnea que probaba
dicha condicin
29
Tests de unidad
Resumen de anotaciones de JUnit 4
@Test(expected = miClaseException.class) indica que se espera que el test lance una excepcin, si
dicha excepcin no se lanza (o se lanza una distinta) el test falla
expected
value
timeout
...
Parmetros
Indica que un mtodo, que debe ser public static void y no tener argumentos, se ejecute una vez antes
que cualquiera de los mtodos de test de la clase
@BeforeClass
@Ignore("not ready yet") @Test public void something() { ... } indica el motivo
@Test(timeout=100) indica que si el tiempo de ejecucin del mtodo es mayor que la cantidad
especificada en milisegundos el mtodo falla
Permite deshabilitar temporalmente un test
@Ignore
Indica que un mtodo, que debe ser public void, se ejecute despus de cualquiera de los mtodos de
test de la clase. Se garantiza que este mtodo se ejecuta incluso aunque el mtodo Before o el
mtodo Test terminen en una excepcin
@After
Indica que un mtodo, que debe ser public static void, se ejecute una vez despues de la ejecucin de
todos los mtodos de test de la clase. El mtodo AfterClass se ejecuta siempre incluso aunque el
mtodo BeforeClass haya terminado en una excepcin
@AfterClass
Indica que un mtodo, que debe ser public void, se ejecute antes que cualquiera de los mtodos de
test de la clase. Se utiliza generalmente para crear instancias que posteriormente comparten todos los
tests
@Before
Indica a JUnit que el mtodo public void que est siendo anotado puede ser ejecutado como un test.
Todas las excepciones lanzadas por el mtodo significarn un fallo en el test. Si no se lanza ninguna
excepcin se entender que el test termin exitosamente
@Test
Significado Anotacin
30
Tests de unidad
Resumen de aserciones de JUnit 4
Comprueba que dos objetos se estn refiriendo al mismo objeto (comparacin
de identidad en vez de igualdad)
(Object unexpected, Object actual) assertSame
Comprueba que la condicin pasada es cierta (boolean condition) assertTrue
Provoca que el test falle () fail
Indica si dos valores float son iguales dentro de un determinado delta (float expected, float actual, float delta)
(Object object)
(Object unexpected, Object actual)
(Object object)
(boolean condition)
(Object expected, Object actual)
(Object[] expecteds, Object[] actuals)
(double expected, double actual, double
delta)
Parmetros
Indica si dos objetos son iguales
Nota: todos los mtodos tienen una segunda versin que acepta como primer parmetro un String en el que mandar un mensaje
Indica si dos arrays de objetos son iguales
Comprueba que un objeto es nulo assertNull
Comprueba que dos objetos NO se estn refiriendo al mismo objeto
(comparacin de identidad en vez de igualdad)
assertNotSame
Comprueba que un objeto NO es nulo assertNotNull
Comprueba que la condicin pasada es falsa assertFalse
Indica si dos valores double son iguales dentro de un determinado delta
assertEquals
Significado Mtodo
31
Tests de unidad
Cmo comprobar la calidad de un test?
Un test no es mejor cuanto ms grande sea o mas
lneas tenga, sino cuanto mejor sea su cobertura
Por cobertura entendemos el nmero de lneas del
cdigo original que prueba el test o tambin el
nmero de ramas en las sentencias condicionales
que recorre
Cul de las siguientes pruebas tiene ms cobertura
4, 100, 400, 2007, 2008
2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016,
etc.
Las herramientas de cobertura de cdigo abierto ms
conocidas son Cobertura
(http://cobertura.sourceforge.net/) y EMMA
((http://emma.sourceforge.net/))
32
Tests de unidad
Cmo usarlas en NetBeans?
NetBeans dispone de un plug-in oficial que realiza pruebas de
cobertura usando EMMA (instalarlo en Tools > Plugins)
33
Tests de unidad
Activamos el proceso de cobertura a la
hora de ejecutar los tests. Como este
proceso modifica los .class compilados
para incluir informacin propia suele ser
muy lento, por lo que por defecto se
aconseja que est desactivado
Eliminamos la prueba del ao 400 para
disminuir intencionalmente la cobertura
del test
Despus de la activacin ejecutamos los
tests de la misma forma que antes
34
Tests de unidad
El test se ejecuta correctamente a pesar
de que no hemos corregido el error en los
aos divisibles por 400
Al ver el cdigo fuente vemos resaltado en
verde aquellas lneas de cdigo por las
que han pasado los tests.
Es claramente visible como la condicin
de que sea divisible por 400 no se ha
probado (no entra en la parte THEN del IF),
luego nuestro test no inclua un juego de
prueba completo y ha sido incapaz de
detectar el error en el cdigo
35
Tests de unidad
Cobertura es ms difcil de usar en
NetBeans al no disponer de un plugin
oficial en la ltima versin del IDE
En esta direccin explican los pasos para
llevarlo a cabo:
http://weblogs.java.net/blog/fabriziogiudic
i/archive/2007/02/automating_test.html
A pesar de esta falta de integracin los
informes de Cobertura son ms visuales y
completos que los de EMMA
36
C:\tmp\Utilities\build.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2 
3 
4 
5 <project name="Utilities" default="default" basedir=".">
6 <description>Builds, tests, and runs the project Utilities.</description>
7 <import file="nbproject/build-impl.xml"/>
61 
69
70 <path id="cobertura.classpath">
71 <fileset dir="${basedir}">
72 <include name="lib/cobertura-1.9/cobertura.jar" />
73 <include name="lib/cobertura-1.9/lib/**/*.jar" />
74 </fileset>
75 </path>
76
77 <taskdef classpathref="cobertura.classpath" resource="tasks.properties"/>
78
79 <target name="cobertura-instrument" depends="init,compile-test,-pre-test-run">
80 <cobertura-instrument todir="${build.test.cobertura.classes.dir}">
81 <fileset dir="${build.classes.dir}">
82 <include name="**/*.class"/>
83 </fileset>
84 </cobertura-instrument>
85 </target>
86
87 <target name="test-coverage"
88 depends="init,compile-test,-pre-test-run,cobertura-instrument, -do-test-run,test-report,-post-
test-run,-test-browse"/>
89
90 <target name="cobertura-coverage-report" depends="init">
91 <cobertura-report srcdir="${src.dir}" destdir="${cobertura.report.dir}"/>
92 <delete file="Serialized" failonerror="false"/>
93 <delete file="cobertura.ser" failonerror="false"/>
94 </target>
95 </project>
Modificaciones que hay que aadir a
fichero build.xml de nuestro proyecto para
poder ejecutar Cobertura desde dentro de
NetBeans
37
Tests de unidad
C:\tmp\Utilities\nbproject\project.properties
62 # Propiedades aadidas para ejecutar cobertura
63 build.test.cobertura.classes.dir=${build.dir}/cobertura-instrumented-classes
64 run.test.classpath=\
65 lib/cobertura-1.9/cobertura.jar:\
66 ${build.test.cobertura.classes.dir}:\
67 ${javac.test.classpath}:\
68 ${build.test.classes.dir}
69 cobertura.report.dir=${build.dir}/cobertura-report
70
71
Modificaciones que hay que aadir a
fichero project.properties de nuestro
proyecto para poder ejecutar Cobertura
desde dentro de NetBeans
38
Tests de unidad
Cobertura mide no slo clases
particulares sino tambin paquetes
39
Tests de unidad
No slo se mira la cobertura en porcentaje
de lnes cubiertas, sino tambin en
porcentaje de ramas condicionales
consideradas
En rojo se marcan las lneas no
consideradas por el cdigo
Los nmeros a la derecha de los nmeros
de lnea indican el nmero de veces que
esa lnea fue ejecutada por los tests
40
Tests de unidad
Jester (http://jester.sourceforge.net/)
Jester es una herramienta para testear los tests
Consiste en hacer una serie de cambios a un cdigo que ha
pasado correctamente los tests de unidad
Si al volver a pasar los tests estos siguen dando resultados
correctos (a pesar de que el cdigo ha cambiado) significa que:
o bien el test no prueba el cdigo cambiado o bien el tests no se
ha diseado correctamente para detectar los cambios
41
Tests de integracin
Los tests de integracin se encargan de analizar la
interaccin entre componentes del sistema
Esta interaccin puede ser entre:
Objetos:
El test instancia varios objetos y llama a los mtodos de unos
objetos desde los otros objetos
Servicios:
Se ejecuta la aplicacin mientras est conectada a servicios
externos, como puede ser un contenedor de EJBs o una base de
datos
Subsistemas:
Una aplicacin diseada en base a capas es normal que tenga la
capa de presentacin separada de la capa de aplicacin que
ejecuta la lgica del sistema. Los tests de integracin
comprobaran en este caso que los requerimientos hechos en la
presentacin pasan a la capa de aplicacin y retornan con la
respuesta correcta.
42
Tests de integracin
Como vemos los lmites entre los tests de unidad y los
tests de integracin son borrosos (sobre todo en el
caso de la interaccin entre objetos)
Los tests de integracin tienen ms sentido cuando en
un test de unidad hemos probado el sistema usando
objetos simulados (mock) y ahora queremos probarlo
con los objetos reales
Por ejemplo, si un objeto accede a una base de datos el
test de unidad puede en principio suponer que la base
de datos est ah y funciona correctamente.
Ser tarea del test de integracin comprobar que la
integracin del sistema con la base de datos es
correcta.
43
Tests de integracin
Tipos de pruebas que involucran acceso a BD
44
Tests de integracin
Ejemplo
Tenemos una clase AccountService que se encarga
de obtener un objeto de tipo Account de una base de
datos usando para ello un objeto AccountManager
45
Tests de integracin
46
Tests de integracin
AccountService utiliza el
interfaz accountManager
para obtener la cuenta del
usuario
Posteriormente utiliza de
nuevo el interfaz
accountManager para
actualizar la cuenta en la
base de datos
47
Tests de integracin
MockAccountManager es un
objeto que utiliza una
Hashtable para simular una
base de datos
Las cuentas en vez de
obtenerse de la base de datos
se obtienen de la HashTable
privada del objeto
MockAccountManager
Los tests de integracin
consistiran en repetir los
tests para las clases
implicadas pero sustituyendo
los objetos simulados por sus
equivalentes reales
48
Tests funcionales
Los tests funcionales comprueban si el resultado final
del sistema es el deseado
En general implican comprobar si se cumplen
correctamente los casos de uso incluidos en la
especificacin
Otros aspectos que analizan son:
Validacin de los datos de entrada.
Comprobar que el sistema es robusto ante entradas invlidas (p. ej.
una edad negativa)
Comprobacin de los datos de salida
Comprobar que los resultados que ofrece el sistema son correctos
y estn correctamente formateados
Anlisis de las transiciones de estados
Comprobar que las transiciones entre estados se realizan de forma
adecuada
Etc.
49
Tests funcionales
El problema de los tests funcionales es que para probar
una funcionalidad completa se deben probar
conjuntamente todas las capas del sistema
(presentacin, modelo, persistencia, etc.)
Resulta complicado automatizar pruebas que realicen
tests funcionales al estilo de JUnit
Aunque existen herramientas especficas para probar,
por ejemplo, GUIs realizados en Java como Jemmy
(http://jemmy.netbeans.org)
Una estrategia habitual es plantear escenarios
(extrados de los casos de uso) y tener personal que se
encarge de testear que los escenarios considerados se
resuelven satisfactoriamente
50
Tests funcionales
Tests funcionales: Normal User Login (Readyset)
This assumes that user has not agreed to terms-of-use already.
Does this work without browser cookies?
Notes and Questions:
visit LoginPage
1. enter usernameOrEmail
2. enter password
3. click Login
4. see the terms-of-use page
5. click Agree at page bottom
6. click Submit
7. see PersonalPage
8. verify welcome message is correct username
Steps:
usernameOrEmail = {testuser, bogususer, testuser@nospam.com,
test@user@nospam.com, empty}
password = {valid, invalid, empty}
Test Data:
User is not already logged in.
User testuser exists, and account is in good standing.
Prereq:
Test that users can log in with the proper username or email address and their password. Purpose:
51
Tests funcionales
Tests funcionales: NetBeans
52
Tests funcionales
Tests funcionales: NetBeans
53
Tests del sistema
Los tests del sistema se realizan sobre un
sistema completo e integrado para evaluar el
cumplimiento de sus especificaciones iniciales
(tanto funcionales como no funcionales)
Puede involucrar analizar los siguientes
aspectos:
Rendimiento
Seguridad
Compatibilidad
Usabilidad
etc.
54
ndice
2. Refactorizacin
Introduccin
Herramientas y ejemplos
55
Refactorizacin
Introduccin
Infra-Ingeniera (Under-Engineering)
Se refiere a cdigo pobremente diseado y es
problema ms comn que afecta al diseo
Los diseos incorrectos surgen por diversas causas
No ha habido tiempo suficiente
No tenemos los conocimientos necesarios
Trabajamos en demasiados proyectos al mismo tiempo
Un diseo incorrecto que funcione correctamente
nunca ser modificado aplicando la norma no
arregles lo que no est roto
A medida que el proyecto va avanzando y se aade
ms cdigo, ms complicado se hace poder corregir
l pobremente diseado. Al final puede llegarse a la
necesidad de realizar una completa reescritura para
adaptarse a las nuevas necesidades.
56
Refactorizacin
Introduccin
Sobre-Ingeniera (Over-Engineering)
Se refiere al hecho de hacer el cdigo ms flexible o
sofisticado de lo necesario
Muchas veces esto se hace para anticipar futuras
necesidades, lo que es razonable, pero predecir el
futuro es una tarea arriesgada.
Si nuestra predicciones no han sido correctas hemos
perdido un tiempo valioso en hacer cdigo
innecesario
Adems, siguiendo la norma no arregles lo que no
est roto este cdigo nunca ser eliminado, lo que
podra complicar futuras modificaciones no previstas
57
Refactorizacin
Introduccin
1
2 interface MessageStrategy
3 { public void sendMessage(); }
4
5 abstract class AbstractStrategyFactory
6 { public abstract MessageStrategy
createStrategy(MessageBody mb); }
7
8 class MessageBody
9 {
10 Object payload;
11
12 public Object getPayload()
13 { return payload; }
14
15 public void configure(Object obj)
16 { payload = obj; }
17
18 public void send(MessageStrategy ms)
19 { ms.sendMessage(); }
20 }
21
22 class DefaultFactory extends AbstractStrategyFactory
23 {
24 private DefaultFactory() { }
25 static DefaultFactory instance;
26
27 public static AbstractStrategyFactory getInstance()
28 {
29 if (instance == null)
30 { instance = new DefaultFactory(); }
31 return instance;
32 }
33
33
34 public MessageStrategy createStrategy(final MessageBody mb)
35 {
36 return new MessageStrategy()
37 {
38 MessageBody body = mb;
39
40 public void sendMessage()
41 {
42 Object obj = body.getPayload();
43 System.out.println((String) obj);
44 }
45 };
46 }
47 }
48
49 class HelloWorld
50 {
51
52 public static void main(String[] args)
53 {
54 MessageBody mb = new MessageBody();
55 mb.configure("Hello World!");
56 AbstractStrategyFactory asf =
DefaultFactory.getInstance();
57 MessageStrategy strategy = asf.createStrategy(mb);
58 mb.send(strategy);
59 }
60 }
Versin del HolaMundo utilizando los
patrones Estrategia, Factora e Instancia
nica
58
Refactorizacin
Introduccin
Refactorizacin
Una refactorizacin es una transformacin que
preserva el comportamiento
Martin Fowler la define como un cambio realizado
en la estructura interna del software que lo hace ms
fcil de entender y modificar, sin cambiar su
comportamiento observable
Generalmente las refactorizaciones realizan pocos
cambios en el cdigo, tratando de minimizar las
posibilidades de hacer algo incorrecto, y
manteniendo el comportamiento observable
Aunque las refactorizaciones hagan pocos cambios,
una serie encadenada de refactorizaciones puede
conseguir una reestructuracin significante del
cdigo
59
Refactorizacin
Introduccin
Ejemplo
En la redaccin de la declaracin de independencia de los
EEUU, Benjamin Franklin revis los escritos de Thomas
Jefferson simplificndolos. Ante las quejas de este ltimo le
puso el siguiente ejemplo:
Cartel original de una tienda de sombreros
John Thompson, sombrerero, hace y
vende sombreros por dinero en efectivo
60
Refactorizacin
Introduccin
Refactorizacin e infra/sobre-ingeniera
La idea es mantener el diseo correcto, pero simple,
sin adelantarnos a futuras e inciertas necesidades
futuras.
Evitamos as la sobre-ingeniera, siempre tratando de
no caer en el otro extremo
Si estas nuevas necesidades aparecen la
refactorizacin permitir adaptar el diseo a las
nuevas funcionalidades
Las pruebas de unidad automatizadas permitirn
comprobar fcilmente que el cdigo refactorizado
tiene la misma funcionalidad que el anterior
61
Refactorizacin
Introduccin
Refactorizacin y TDD
62
Refactorizacin
Introduccin
Principales motivaciones de la refactorizacin
Hacer el cdigo fcil de cambiar o que sea fcil de
aadir una nueva caracterstica
Reducir la complejidad para facilitar la comprensin
Eliminar repeticiones innecesarias
Mejorar el diseo del cdigo existente
Mejorar el rendimiento del cdigo existente
Permitir el uso del cdigo para otras necesidades
distintas (o ms generales) de las iniciales
63
Refactorizacin
Ejemplos y herramientas
Encapsular campo (Encapsulate Field)
Situacin:
Uno o varios de los campos (atributos) del objeto son pblicos
Refactorizacin:
El objetivo es hacerlos privados y proveer de mtodos de lectura y
escritura
64
Refactorizacin
Extraer interfaz (Extract
Interface)
Situacin:
Varios clientes usan un
determinado
subconjunto del interfaz
pblico de una clase
Situacin:
Separar este
subconjunto en un
interfaz y hacer que la
clase original
implemente dicho
interfaz
65
Refactorizacin
Extraer mtodo
(Extract Method)
Situacin:
Un fragmento de
cdigo puede ser
agrupado
Situacin:
Convertir dicho
fragmento en un
mtodo y darle un
nombre que
describa su
propsito
66
Refactorizacin
Renombrar mtodo (Rename Method)
Situacin
El nombre del mtodo no refleja su propsito
Refactorizacin
Cambiar el nombre del mtodo
67
Refactorizacin
El uso de herramientas es vital en el desarrollo
de la refactorizacin
Una herramienta de automatizacin de
refactorizaciones permite:
Configurar las refactorizaciones de forma sencilla
para que se adapten a nuestros requisitos
Mostrar los cambios antes de que estos sucedan
Realizar los cambios de forma automtica
Deshacer los cambios si fuera necesario
Veamos Encapsular campos en NetBeans
68
Refactorizacin
69
Refactorizacin
70
Refactorizacin
71
Refactorizacin
72
Refactorizacin
73
Refactorizacin
74
Refactorizacin
Ejercicio
Prueba a aplicar sobre ese cdigo las
refactorizaciones de extraer interfaz (por
ejemplo un producto tiene una descripcin y
un precio), extraer mtodo (el clculo del IVA
se hace en un mtodo aparte) y renombrar
mtodo
75
Bibliografa
Libros
JUnit in Action, Vincent Massol & Ted Husted, Manning, 2004
Test-Driven Development By Example, Kent Beck, Addison
Wesley, Boston, MA, 2002
Refactoring: Improving the Design of Existing Code, Martin
Fowler, Addison-Wesley, Boston, MA, 2000.
Refactoring to Patterns, Joshua Kerievsky, Addison-Wesley,
Boston, MA, 2005
Enlaces en Internet
Test Driven Development URL:
http://en.wikipedia.org/wiki/Test-driven_development
Refactoring Home Page URL: http://www.refactoring.com

Tema Tests Java PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tema Tests Java PDF

Enviado por

Direitos autorais:

Formatos disponíveis

LIDIA

Você também pode gostar