Diseo y realizacin de pruebas

3.1. Introduccin
Las pruebas de software consisten en verificar un producto de software antes de
su puesta en marca. Constituyen una de las etapas del desarrollo de software, y
bsicamente consiste en probar la aplicacin construida. Se integran dentro de las d
iferentes fases del ciclo de vida del software.
La ejecucin de pruebas de un sistema involucra una serie de etapas:
- Planificacin de pruebas
- Diseo y construccin de casos de prueba
- Definicin de los procedimeintos de prueba
- Ejecucin de las pruebas
- Registro de resultados obtenidos
- Registros de errores encontrados
- Depuracin de los errores
- Informe de los resultados obtenidos
3.2. Tcnicas de diseo de casos de prueba
**Caso de prueba**. Conjunto de entradas, condiciones de ejecucin y resultados es
perados, desarrollo para conseguir un objetivo particular o condicin de prueba. P
ara llevar a cabo un caso de prueba, es necesario:
- Definir las precondiciones y post condiciones.
- Identificar unos valores de pruebas.
- Conocer el comportamiento que debera tener el sistema ante dichos valores.
Tras realizar ese anlisis e introducir dichos datos en el sistema, se observa si
su comportamiento es el previsto o no y por qu. De esta forma se determina si el
sistema ha pasado o no la prueba.
Para llevar a cabo el diseo de casos de prueba se utilizan dos tcnicas o enfoques:
- **Pruebas de caja blanca**. Se centran en validar la estructura interna dle pr
ograma (necesitan conocer los detalles procedimentales del cdigo).
- **Pruebas de caja negra**. Se centran en validar los requisitos funcionales si
n fijarse en el funcionamiento interno del programa (necesitan saber el funciona
lidad que el cdigo ha de proporcionar).
Estas pruebas no son excluyentes y se pueden combinar para descubirir diferentes
tipos de errores.
3.2.1. Pruebas de caja blanca
Conocidas tambin como **pruebas estructurales** o **pruebas de caja de cristal**.
Se basan en el minucioso examen de los detalles procedimentales del cdigo de la
aplicacin Mediante esta tcnicas se pueden obtener casos de prueba que:
- Garanticen que se ejecutan al menos una vez todas los camino independientement
e de cada mdulo.
- Ejecuten todas las sentencias al menos una vez.
- Ejecuten todas las decisiones lgicas en su parte verdadera y en su parte falsa.
- Utilicen todas las estructuras de datos internas para aseguirar su validez.
Una de las tcnicas utilizadas para desarrollar los casos de prueba de caja blanca
es la **prueba del camino bsico**.
3.2.2. Pruebas de caja negra
Estas pruebas se llevan a cabo sobre la interfaz del software, no hace falta con
ocer la estructura interna del programa ni su funcionamiento. Se pretende obtene
r casos de prueba que demuestren que las funciones del software son operativas,
es decir, que las salidas devuelvan la aplicacin son las esperadas en funcin de la
s entradas que se proporcionen.
A este tipo de pruebas tambin se les llama **pruebas de comportamiento**.
El sistema se considera como una caja negra, cuyo comportameinto solo se puede d
eterminar estudiando las entradas y las salidas que devuelve en funcin de las ent
radas suministradas.
Con este tipo de pruebas se intenta encontrar errores como:
- Funcionalidades incorrectas o ausentes.
- Errores de interfaz.
- Errores en estructuras de datos o en accesos a bases de datos externas.
- Errores de rendimiento.
- Erroes de inicializacin y finalizacin.
Existen diferentes tcnicas para confeccionar los casos de pruebas de caja negra:
- Clases de equivalencia
- Anlisis de valores lmite
- Mtodos basados en grafos
- Pruebas de comparacin
3.3. Estrategia de pruebas del software.
La **estrategia de pruebas del sofware** se puede analizar en forma de espiral:
- En el vrtice de la espiral comienza la **prueba de unidad**. Se centra en la un
idad ms pequea del software, el mdulo tal y como est implementado en cdigo fuente.
- La prueba avanza para llegar a la **prueba de integracin**. Se toma los mdulos p
robados mediante la prueba de unidad y se construye una estructura de programa q
ue est de acuerdo con lo que dicta el diseo. El foco de atencin esta el diseo.
- La espiral avanza llegando a la **prueba de validacin**. Prueba de software en
el entorno de trabajo con intervencin del usuario final. Se validan los requisito
s establecidos con parte del anlisis de requisitos de software comparndolos con el
sistema construido.
- Finalmente se llega a la **prueba del sistema**. Verifica que cada elemento en
caje de forma adecuada y se alcanza la funcionalidad y rendimiento total. Se pru
eba como un todo el software y otros elementos del sistema.
3.3.1. Pruebas de unidad
En este nivel se prueba cada unidad o mdulo con el objetivo de eliminar errores e
n la interfaz y la lgica interna. Esta actividad utiliza tcnicas de caja negra y c
aja blanca. Se realizan sobre componentes como:
- La interfaz del mdulo
- Las estructuras de datos locales
- Las condiciones lmite
- Todos los caminos independientes de la estructura de control
- Todos los caminos de manejo de errores
Algunas herramientas que se utilizan para pruebas unitarias son:
- JUnit
- CPPUnit
- xUnit
- PHPUnit
3.3.2. Pruebas de integracin
En este tipo de prueba se observa cmo interaccionan los distintos mdulos. Aunque l
os mdulos funcionen correctamente por separado, debemos comprobar si funcionan ju
ntos.
**Enfoques**:
- **Integracin no incremental**. Se prueba cada mdulo por separado y luego se comb
inan todos de una vez y se prueba el programa completo. En este enfoque se encue
ntran gran cantidad de errores y la correcin se hace difcil.
- **Integracin incremental**. El programa completo se va construyendo y probando
en pequeos segmentos, en este caso los errores son ms fciles de localizar. Se dan d
os estrategias:
- **Ascendente**. La construccin y prueba del programa empieza desde los
mdulos de los niveles ms bajos de la estructura.
- **Descendente**. La integracin comienza en el mdulo principal movindose h
acia abajo por la jerarqua de control.
3.3.3. Pruebas de validacin
La validacin se consigue cuando el software funciona de acuerdo con las expectati
vas razonables del cliente definidas en el documento de especificacin de requisit
os de software.
Se llevan a cabo pruebas de caja negra. Las tcnicas a utilizar:
- **Prueba Alfa**. Llevada a cabo por el cliente o usuario en el lugar de desarr
ollo. El cliente utiliza el software de forma natural bajo la observacin del desa
rrollador.
- **Prueba Beta**. Llevada a cabo por los usuarios finales del software en su lu
gar de trabajor. El desarrollador no est presente. El usuario registra todos los
problemas e informa al desarrollador en los intervalos definidos en el plan de p
ruebas. Segn la informacin recibida, el desarrollador hace modificaciones y lanza
nuevas versiones.

3.3.4. Pruebas del sistema

Formada por un conjunto de pruebas cuya misin es ejercitar profundamente el softw
are, son las siguientes:
- **Prueba de recuperacin**. En este tipo de prueba se fuerza el fallo del softwa
re y se verifica que la recuperacin se lleva a cabo apropiadamente.
- **Prueba de seguridad**. Esta prueba intenta verificar que el sistema est prote
gido frente accesos ilegales.
- **Prueba de resistencia** (stress). Trata de enfrentar el sistema con situacio
nes que demandan gran cantidad de recursos, por ejemplo, diseando casos de prueba
que requieran el mximo de memoria, incrementando la frecuencia de datos de entra
da que dan problemas en un sistema operativo virtual.
3.4. Documentacin para las pruebas
Documentos que pueden producirse durante el proceso de prueba:
- **Plan de pruebas**. Describe el alcance, enfoque, recuros y calendario de las
actividades de prueba. Identifica los elementos a probar, las caractersticas que
se van a probar, las tareas que se van a realizar, el personal responsable de c
ada tarea y riesgos asociados al plan.
- **Especificaciones de prueba**. Estn cubiertas por tres tipos de documentos:
- **Especificaciones del diseo de la prueba**.
- **Especificaciones de los casos de prueba**.
- **Especificaciones de los procedimeintos de prueba**.
- **Informes de prueba**. Se definen cuatro tipos de documentos:
- **Informe que identifica los elementos** que estn siendo probados.
 - **Registro de las pruebas**
- **Informe de incidentes de pruebas**
- **Informe de resumen de las actividades de pruebas**
3.5. Pruebas de cdigo
Las **pruebas de cdigo** consisten en la ejecucin del programa con el objetivo de
encontrar errores. Se parte para su ejecucin de un conjunto de entradas y una ser
ie de condiciones de ejecucin, se observan y se registran los resultados y se com
paran con los resultados esperados.
Se observar si el compartamiento del programa es el esperado o no.
Para las pruebas de cdigo se van a mostrar diferentes tcnicas que dependen del tip
o de enfoque utilizado:
- **Pruebas de caja blanca**. Se centran en la estructura interna.
- **Pruebas de caja negra**. Se centran en las funciones, entradas y salidas.
3.5.1. Prueba del camino bsico
Tcnica de prueba de caja blanca que permite al diseador de casos de prueba obtener
una medida de la complejidad lgica de un diseo procedimental y usar esa medida co
mo gua para la definicin de un conjunto bsicos de caminos de ejecucin.
Los casos de prueba obtenidos del conjunto bsico de caminos garantizan que durant
e la prueba se ejecuta por lo menos una vez cada sentencia del programa.
Para obtener la medida de la complejidad lgica emplearemos una representacin del f
lujo de control, **grafo de flujo**.
Complejidad ciclomtica
La **complejidad ciclomtica** es la mtrica del software que proporciona una medida
cuantitativa de la complejidad lgica de un programa.
En el contexto del mtodo de **prueba del camino bsico**, la complejidad ciclomtica
establece el nmero de caminos independientes del conjunto bsico de caminos de ejec
ucin de un programa y, por tanto, el nmero de casos de prueba que se deben ejecuta
r para asegurar que cada sentencia se ejecuta al menos una vez.
La **complejidad ciclomtica V(G)** puede calcularse de tres formas:
1. **V(G)** = Nmero de regiones del grafo
2. **V(G)** = Aristas - Nodos + 2
3. **V(G)** = Nodos predicado + 1
Se establecen las siguientes valores de referencia de la complejidad ciclomtica:
- **Entre 1 y 10**. Programas o mtodos sencillos (sin mucho riesgo).
- **Entre 11 y 20**. Programas o mtodos complejos (riesgo moderado).
- **Entre 21 y 50**. Programas o mtodos ms complejos (riesgo alto).
- **Ms de 50**. Programas o mtodos no testables (riesgo muy alto).
El valor de **V(G)** nos da el nmero de caminos independientes del conjunto bisco
de un programa. Un camino independiente es cualquier camino del programa que int
roduce, por lo menos, un nuevo conjunto de sentencias de proceso o una condicin.
En trminos de *diagram de flujo*, un camino independiente est constituido por al m
enos una arista que no haya sido recorrida anteriormente a la definicin del camin
o.
Obtencin de los casos de prueba
El ltimo paso de la **prueba del camino bsico** es construir los casos de prueba q
ue fuerzan la ejecucin de cada camino. Con el fin de comprobar cada camino, debem
os escoger los casos de prueba de forma que las condiciones de los nodos predica
dos estn adecuadamente establecidas.

3.5.2. Particin o clases de equivalencia

La **particin equivalente** es un mtodo de pruebas de caja negra que divide los va
lores de los campos de entrada de un programa en clases de equivalencia.
Para identificar las clases de equivalencia se examina cada condicin de entrada y
se divide en dos o ms grupos. Se definen dos tipos de clases de equivalencia:
- **Clases vlidas**. Valores de entrada vlidos.
- **Clases no vlidas**. Valores de entrada no vlidos.
Las clases de equivalencia se definen segn las siguientes directrices:
- Si una condicin de entrada se especifica un **rango**, se define una clase de e
quivalencia vlida y dos no vlidas.
- Si una condicin de entrada requiere un **valor especfico**, se define una clase
de equivalencia vlida y dos no vlidas.
- Si una condicin de entrada especifica un **miembro de un conjunto**, se define
una clase de equivalencia vlida y una no vlida.
- Si una condicin de entrada es **lgica**, se define una clas de equivalencia vlida
y no vlida.
3.5.3. Anlisis de valores lmite
El **anlisis de valores lmite** se basa en que los errores tienden a producirse co
n ms probabilidad (por razones que no estn del todo claras) en los lmites o extremo
s de los campos de entrada.
Esta tcnica complementa a la anterior y los casos de prueba elegidos ejercitan lo
s valores justo por encima y por debajo de los mrgenes de la clase de equivalenci
a. Adems no solo se centra en las condiciones de entrada, sino que tambin se explo
ran las condiciones de salida definiendo las clases de equivalencia de salida.
Las reglas son las siguientes:
- Si una condicin de entrada especifica un **rango**, se deben disear casos de pru
eba para los lmites del rango y para los valores justo por encima y por debajo de
l rango.
- Si una condicin de entrada especifica un **nmero de valores**, se deben disear ca
sos de prueba para los valores mximo, mnimo, un valor justo por encima del mximo y
uno por debajo del mnimo.
- Si una condicin de salida especifica un **rango**, se deben disear casos de prue
ba para los lmites del rango y para los valores justo por encima y por debajo del
rango.
- Si una condicin de salida especifica un **nmero de valores**, se deben disear cas
os de prueba para los valores mximo, mnimo, un valor justo por encima del mximo y u
no por debajo del mnimo.
- Si las estructuras de datos internas tienen lmites prestablecidos, hay que aseg
urarse de disear casos de prueba que ejercite la estructura de datos en sus lmites
, primer y ltimo elemento.
3.6. Herramientas de depuracin
El proceso de depuracin comienza con la ejecucin de un caso de prueba. Se evalan lo
s resultados de la ejecucin y fruto de esa evaluacin se comprueba que hay una falt
a de correspondencia entre los resultados esperados y los obtenidos realmente. E
l proceso de depuracin siempre tiene uno de los dos resultados siguientes:
1. Se encuentra la causa del error, se corrige y se elimina.
2. No se encuentra la causa del error. En este caso, la persona encargada de la
depuracin debe sospechar la causa, disear casos de prueba que ayuden a confirmar s
us sospechas y volver a repetir las pruebas para identificar los errores y corre
girlos (pruebas de regresin, repeticin selectiva de pruebas para detectar fallos i
ntroducidos durante la modificacin).
Al desarrollar programas cometemos dos tipos de errores:
- **Errores de compilacin**. Fciles de corregir, ya que normalmente usamos un IDE
para codificar y al escribir las sentencias, el entorno proporciona informacin de
la localizacin del error y cmo solucionarlo.
- **Errores lgicos**. Dficiles de detectar, ya que el programa se puede compilar c
on xito (no hay errores sintcticos), sin embargo, su ejecucin puede devolver result
ados inesperados y errneos.
Los entornos de desarrollo incorporan una herramienta conocida como **depurador*
* (debugger) para ayudarnos a resolver este tipo de errores. El depurador nos pe
rmite analizar el cdigo del programa mientras se ejecuta. Permite establecer punt
os de interrupcin o de ruptura, suspender la ejecucin del programa, ejecutar el cdi
go paso a paso y examinar el contenido de las variables.
Depurador en Eclipse
En **Eclispe**, podemos lanzar el depurador de varias formas:
- Pulsando en el botn **Debug**
- Seleccionando el men **Run > Debug**
- Clic derecho sobre la clase a ejecutar y seleccionamos **Debug As > Java Appli
cation**
Tambin es conveniente abrir la vista de depuracin desde:
- Men Window > Open perspective > Debug
Se muestra la informacin relativa al programa que se est ejecutando. No obstante,
al ejecutar el programa en modo depuracin, si la vista no est abierta, se muestra
un mensaje desde el que confirmaremos su apertura. Al cambiar a la vista depurac
in se muestra en la barra de herramientas una serie de botones: para continuar la
ejecucin, suspenderla, pararla, para meterse dentro de la primera lnea de un mtodo
, avanzar un paso la ejecucin, avanzar el programa hasta salir del mtodo actual, e
tc.
En esta vista se puede ver varias zonas:
- En la vista **Editor** se va marcando la traza de ejecucin del programa mostrndo
se una flechita azul en el margen izquierdo.
- En la vista **Debug** se muestran los hijos de ejecucin, en este caso solo se m
uestra un hilo (Thread[main]) y debajo la clase en la que est parada la ejecucin m
ostrando el nmero de la lnea
- En la vista **Inspect** se permiten ver los valores de las variables y de los
puntos de ruptura que intervienen en el programa en un instante determinado. Des
de aqu se pueden modificar el valor de las variables, basta con hacer clic en el
valor y cambiarlo; el nuevo valor se usar en los siguientes pasos de ejecucin. Tam
bin des de la pestaa **Breakpoints** se puede activar o desactivar un breakpoint,
eliminarlo, configurarlo para que la ejecucin se detenga cuando se pase por l un d
eterminado nmero de veces.
- En la vista **Console** se muestra la consola de ejecucin del programa que se e
st depurando. Es la vista sobre la que se redirecciona tanto la entrada como la s
alida estndar.
[...]
Como resumen podemos decir que el depurador nos permite ejecutar un programa de
forma controlada con el fin de probarlo, encontrar la causa de error o incluso c
onocer mejor su funcionamiento. Proporciona las siguientes funciones:
- Ejecutar el programa paso a paso. Tras cada paso, el usuario recupera el contr
ol.
- Detener la ejecucin del programa cuando alcance una determinada lnea del cdigo o
cuando se cumpla una condicin.
- A cada paso de ejecucin se puede conocer el valor de las variables o expresione
s.
3.7. Pruebas unitarias con JUnit
**JUnit** es una herramienta para realizar pruebas unitarias automatizadas. Esta
integrada en Eclipse, por lo que no es necesario descargarse ningn paquete para
poder usarla. Las pruebas unitarias se realizan sobre una clase para probar su c
omportamiento de modo aislado independientemente del resto de clases de la aplic
acin. Aunque esto no siempre es as, porque una clase a veces depende de otras clas
es para poder llevar a cabo su funcin.
3.7.1. Creacin de una clase de prueba
Para empezar a usar **JUnit** crearemos un nuevo proyecto en Eclipse, y crearemo
s la clase a probar que, en este caso, se llama *Calculadora*.
A continuacin, hay que crear la clase de prueba
- Con la clase *Calculadora* seleccionada
- Clic derecho sobre New > JUnit Test Case
- Seleccionar *New JUnit 4 test*
El resto de valores los dejamos por defecto. El nombre la clase de prueba sera *
CalculadoraTest*.
- Clic sobre *Next*
Ahora tenemos que seleccionar los mtodos que queremos probar:
- Marcar los 4 mtodos (suma(), resta(), mutiplica(), divide())
- Clic sobre *Finish*
A continuacin se abre una ventana indicndonos que la librera **JUnit 4** no est incl
uida en nuestro proyecto:
- Pulsar *OK*
Para que la clase de prueba se incluya en un paquete diferente al de la clase a
probar se escrbie el nombre del paquete en el campo *Package*.
La clase de prueba se crea automticamente, se observan una serie de caractersticas
:
- Se crean 4 mtodos de prueba, uno para cada mtodo seleccionado anteriormente.
- Los mtodos son pblicos, no devuelven nada y no reciben ningn argumento.
- El nombre de cada mtodo incluye la palabra test al principio *testSuma()*, *tes
tResta()*, *testMultiplica()* y *testDivide()*.
- Sobre cada uno de los mtodos aparece la anotacin *@Test* que indica al compilado
r que es un mtodo de prueba.
- Cada uno de los mtodos de prueba tiene una llamada al mtodo *fail()* con un mens
aje indicando que todava no se ha implementado el mtodo. Este mtodo hace que el tes
t termina con fallo lanzando el mensaje.
3.7.2. Preparacin y ejecucin de las pruebas
Antes de preparar el cdigo para los mtodos de prueba, veamos una serie de mtodos de
**JUnit** para hacer las comprobaciones, todos estos mtodos devuelven un tipo *v
oid*:
- **assertTrue**(boolean expresin) o (String mensaje, ...). Comprueba que la expr
esin se evale a *true*. Si no es *true* y se incluye el String, al producirse erro
r se lanzar el mensaje.
- **assertFalse**(boolean expresin) o (String mensaje, ...). Comprueba que la exp
resin se evale a *false*. Si no es *false* y se incluye el String, al producirse e
rror se lanzar el mensaje.
- **assertEquals**(valorEsperado, valorReal) o (String mensaje, ...). Comprueba
que el *valorEsperado* sea igual al *valorReal*. Si no son iguales y se incluye
el String, entonces se lanzar el mensaje.
- **assertNull**(Object objeto) o (String mensaje, ...). Comprueba que el *objet
o* sea null. Si no es null y se incluye el String, al producirse error se lanzar
el mensaje.
- **assertNotNull**(Object objeto) o (String mensaje, ...). Comprueba que el *ob
jeto* no sea null. Si es null y se incluye el String, al producirse error se lan
zar el mensaje.
- **assertSame**(Object objetoEsperado, Object objetoReal) o (String mensaje, ..
.). Comprueba que *objetoEsperado* y *objetoReal* sean el mismo objeto. Si no so
n el mismo y se incluye el String, al producirse error se lanzar el mensaje.
- **fail**() o (String mensaje). Hace que la prueba falle. Si se incluye el Stri
ng la prueba falla lanzando el mensaje.
Vamos a crear el cdigo de prueba para el mtodo *testSuma()* que probar el mtodo *sum
a()* de la clase *Calculadora*. Lo primero que hacemos es crear una instancia de
la clase *Calculadora*, que llamamos al mtodo *suma()* llevando los valores a su
mar y comprobamos los resultados con el mtodo *assertEquals()*. En el primer parme
tro de este ltimo mtodo escribimos el resultado esperado al realizar el mtodo *suma
()* y como segundo parmetro asignamos el resultado obtenido al llamar a dicho mtod
o.
Si pulsamos ahora el botn *Run* para ejecutar el test, se mostrarn algunos errores
, ya que no se han implementado todos los test de pruebas. Tambin se puede ejecut
ar la clase de prueba:
- Clic derecho sobre la clase de prueba
- Seleccionar Run As > JUnit Test
En ambos casos se abre la pestaa de **JUnit** donde se muestran los resultados de
ejecucin de las pruebas.
Al lado de cada prueba aparece un icono con una marca:
- Una marca de verificacin verde indica prueba superada.
- Una aspa azul indica fallo.
- Una aspa roja indica error.
El resultado esperado de la ejecucin de nuestra prueba ser:
- **Runs**: 4/4
- **Errors**: 0
- **Failures**: 3
En el contexto de **JUnit** un fallo es una comprobacin que no se cumple, un erro
r es una excepcin durante la ejecucin del cdigo. En esta prueba solo se ha realizad
o satisfactoriamente la prueba con el mtodo *testSuma()* que muestra un icono con
marca de verificacin verde al lado, el resto de pruebas han fallado.
Rellenamos el resto de los mtodos de prueba escribiendo en los mtodos *assertEqual
s()* con el valor esperado y el resultado de realizar la operacin con los nmeros i
ndicados.
Ahora al ejecutar la clase de prueba el resultado que muestra ser:
- **Runs**: 4/4
- **Errors**: 0
- **Failures**: 0
Nos indica que se han realizado 4 pruebas, ninguna ha provocado error y ninguna
ha provocado fallo.
Para ver la diferencia entre un fallo y un error vamos a cambiar el cdigo del mtod
o *multiplica()* para que produzca un fallo haciendo que el valor esperado y el
valor real no coincidan e incluyendo un mensaje, y el cdigo del mtodo *divide()* p
ara que genere un error asignando el valor 0 al segundo parmetro (ser el denominad
or de la divisin, al dividir por 0 se produce una excepcin.
Al pulsar en los test que han producido fallos o errores se muestra la traza de
ejecucin.
El siguiente test comprueba que la llamada al mtodo *divide()* devuelve la excepc
in *ArithmeticException* al dividir 20 entre 0; por tanto, sale por la clusula *ca
tch*. Si no se lanza la excepcin, se lanza el mtodo *fail()* con un mensaje indica
ndo que se ha producido un fallo al probar el test. La prueba tiene xito si se pr
oduce la excepcin y falla en caso contrario.
3.7.3. Tipos de anotaciones
En todos los mtodos de prueba anteriores se repeta la lnea *Calculadora calcu = new
Calculadora(20, 10);* esta sentencia de inicializacin se puede escribir una sola
vez dentro de la clase.
**JUnit** disponde de una serie de anotaciones que permiten ejecutar cdigo antes
y despus de las pruebas:
- **@Before**. Si anotamos un mtodo con esta etiqueta, el cdigo ejecutado antes de
cualquier mtodo de prueba. Este mtodo se puede utilizar para inicializar datos, p
or ejemplo, en una aplicacin de acceso a base de datos se puede preparar la base
de datos si vamos a usar un array para las pruebas se puede inicializarse aqu. Pu
ede haber varios mtodos en la clase de prueba con esta anotacin.
- **@After**. Si anotamos un mtodo con esta etiqueta el cdigo ser ejecutado despus d
e la ejecucin de todos los mtodos de prueba. Se puede utilizar para limpiar datos.
Puede haber varios mtodos en la clase de prueba con esta anotacin.
Otras anotaciones a destacar son:
- **@BeforeClass**. Solo puede haber un mtodo con esta etiqueta. El mtodo marcado
con esta anotacin es invocado una vez al principio del lanzamineto de todas las p
ruebas. Se suele utilizar para inicializar atributos comunes a todas las pruebas
o para realizar acciones que tardan un tiempo considerable en ejecutarse.
- **@AfterClass**. Solo puede haber un mtodo con esta anotacin. Este mtodo es invoc
ado una sola vez cuando finalicen todas las pruebas.
3.7.4. Pruebas parametrizadas
Supongamos que queremos ejecutar una prueba varias veces con distintos valores d
e entrada, por ejemplo, queremos probar el metodo *divide()* con diferentes valo
res.
**JUnit** nos permite generar parmetros para lanzar varias veces una prueba con d
ichos parmetros. Para poder hacer esto, seguiremos estos pasos:
- Debemos aadir la etiqueta *@RunWith(Parameterized.class)* a la clase de prueba,
con esto indicamos que la clase va a ser usada para realizar una batera de prueb
as. En esta clase se debe declarar un atributo por cada uno de los parmetros, en
cada prueba. Para probar el mtodo *divide()* o cualquiera de los dems mtodos defini
remos 3 parmetros, 2 de ellos para los nemros con los que se realiza la operacin y
el tercero para recoger el resultado; el constructor tendr el siguiente aspecto:
public CalculadoraTest(int nume1, int nume2, int resul) {
...
}
- Lo siguiente es definir un mtodo anotado con la etiqueta *@Parameters*, que ser
el encargado de devolver la lista de valores a probar. En este mtodo, se definirn
filas de valores para *num1*, *num2* y *resul* (en el mismo orden en que estn def
inidos en el constructor).
En el siguiente ejemplo para probar el mtodo *divide()* usamos tres casos de prue
ba, dos de ellos correctos y uno con resultado errneo. La clase *CalculadoraTest4
*, quedara as:
import static org.junit.Assert.*;
import java.util.Arrays;
import java.util.Collection;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@RunWith(Parameterized.class)
public class CalculadoraTest4 {
private int nume1;
private int nume2;
private int resul;
public CalculadoraTest4(int nume1, int nume2, int resul) {
this.nume1 = nume1;
this.nume2 = nume2;
this.resul = resul;
}
@Parameters
public static Collection<Object[]> numeros() {
return Arrays.asList(new Object[][] {
{ 20, 10, 2}, {30, -2, -15}, {5, 2, 3}
});
}
@Test
public void testDivide() {
Calculadora calcu = new Calculadora(nume1, nume2);
int resultado = calcu.divide();
assertEquals(resul, resultado);
 }
}
La ejecucin produce la salida se muestra en corchetes la prueba de que se trata.
En este caso no se prueban todos los mtodos a la vez, ya que la lista de valores
para las pruebas se ha preparado para la operacin de dividir.
3.7.5. Suite de pruebas
A veces nos interesa ejecutar varias clases de prueba una tras otra. Es el caso
del ejemplo anterior que no podemos ejecutar las pruebas parametrizadas para tod
os los mtodos en una nica clase. **JUnit** proporciona el mecanismo llamado **Test
Suites** que agrupa varias clases de prueba para que se ejecuten una tras otra.
Supongamos que se han creado pruebas parametrizadas para los mtodos *suma()*, *re
sta()* y *multiplica()*; y el nombre para las clase de prueba es *CalculadoraTes
tSuma*, *CalculadoraTestResta* y *CalculadoraTestMultiplica*.
Entonces para crear la suite de pruebas pulsamos en la opcin de men:
- File > New > Other > Java > JUnit > JUnit Test Suite
- Clic en el botn *Next*
Desde la siguiente pantalla elegimos las clases que formarn parte de la suite de
pruebas
- Marcamos la opcin *New JUnit 4 suite*.
- Le damos un nombre, *VariasPruebas*
- Pulsamos en *Finish*
Ahora, tenemos nuestra suite de pruebas preparadas. Donde hay que destacar dos a
notaciones. La primera *@RunWith(Suite.class)* indica a **JUnit** que la clase e
s una suite de pruebas y en la segunda anotacin *@SuiteClasses()* se indican las
clases que forman parte del conjunto de pruebas y que son las que se van a ejecu
tar. Dentro de la clase no se genera ninguna lnea de cdigo.
DBUnit
**DBUnit** es una extensin de **JUnit** que nos permite realizar test unitarios d
e clases que interactuan con bases de datos. Utiliza ficheros XML para cargar lo
s datos de prueba en la base de datos. Una vez cargadas las tablas con los datos
de prueba se lanza la prueba. Al finalizar la misma se restauran los datos en l
a base datos para que el siguiente test de prueba se encuentre la base de datos
en el estado original. Con esto se evita que datos corruptos procedentes de prue
bas fallidas queden en la base de datos ocasionando problemas a las siguientes p
ruebas.
Los componentes principales son:
- **IDatabaseConnection**. Interfaz que representa una conexin **DBUnit** a una b
ase de datos.
- **IDataSet**. Interfaz que representa una coleccin de tablas.
- **DatabaseOperation**. Clase abstracta que representa la operacin que se va a r
ealizar sobre la base de datos antes y despus de cada prueba.