Ingenieria de Software II

Gestin de Pruebas
Pruebas de aceptacin
Pruebas unitarias: JUnit
Ing. de Sistemas - Lic. Ivan Fernandez Daza

ndice
Pruebas: qu es probar?
Cmo hacer pruebas con JUnit
Enfoque de las pruebas
caja negra | caja blanca
cobertura

Algunas Palabras

informales

Pruebas

fallos

desarrollo

pruebas

falla

dnde falla qu?

pasa
pruebas de
aceptacin

falla

pasa

Obje:vo
El obje6vo nico de las pruebas es
encontrar errores en el cdigo
antes de que aparezcan en ejecucin

Una batera de pruebas es tanto mejor

cuantos menos errores pasan desapercibidos

Probar es provocar

Aforismos
Probar es buscar fallos
Cuantos ms fallos se encuentran en una unidad,
ms fallos 6ene
cuando se iden6ca un bicho malo
hay que machacarlo

El que desarrolla est incapacitado para probar:

deben ser equipos de trabajo enfrentados
Es bueno disear para probar
Las pruebas tambin pueden tener fallos

Enfoque psicolgico
El que desarrolla
quiere comprobar que el programa funciona
con todo lo que se le ocurre que debe ir

El que prueba
intenta que el programa falle
con todo lo que se le ocurre que puede fallar

Caso de prueba
Debe denir
un obje6vo: qu error buscamos?
unos datos de prueba
unos resultados esperados
un procedimiento de ejecucin
un criterio para saber si
la prueba PASA
la prueba FALLA
la prueba no es CONCLUYENTE

/** javadoc

java

JUnit

Plan de pruebas
batera de casos
denir grupos de pruebas (macro-obje6vos)
denir casos de pruebas (micro-obje6vos)

ndice
Pruebas: qu es probar?
Cmo hacer pruebas con JUnit
Enfoque de las pruebas
caja negra | caja blanca
cobertura

Algunas Palabras

10

JUnit

Paquete ampliamente u6lizado

para automa6zar pruebas de cdigo Java
h9p://www.junit.org/

h9p://downloads.sourceforge.net/junit/junit-4.5.jar

empotrado en BlueJ, DrJava, ...

si su IDE no lo con6ene
1. descargar de www.junit.org
2. ejecutar con main

Un grupo de pruebas es una clase java

Una prueba es un mtodo java
11

cheros de pruebas
import junit.framework.TestCase;
public class Test_NOMBRE_DEL_GRUPO
extends TestCase {
public void test_NOMBRE_DE_LA_PRUEBA_1 () {
// planteamiento del escenario
assertEquals(valor_esperado, valor_obtenido);
}
public void test_NOMBRE_DE_LA_PRUEBA_n () {
// planteamiento del escenario
assertEquals(valor_esperado, valor_obtenido);
}
}

12

Reglas
extendsTestCase
Mtodos de prueba

public void testXXX() [throws ]

1 o ms aserciones por mtodo
se ejecutarn en algn orden, no obligatorio

Aserciones: coleccin muy amplia (ver apuntes)

assertEquals(T esperado, T resultado)

assertNull(Object resultado)
assertNotNull(Object resultado)
assertTrue(boolean resultado);
assertFalse(boolean resultado);
...
h9p://junit.org/apidocs/junit/framework/Assert.html
16

Varios assert por test

Pruebas encadenadas
si una prueba falla, no se ejecutan las siguientes

Pruebas individuales
fallos singularizados

Si pasan todos los tests

es indiferente

Si falla alguno
las pruebas encadenadas no avanzan

18

Excepciones
El cdigo puede lanzar excepciones
falla si ...
lanza excepciones no previstas
no lanza excepciones previstas

Se programa de forma que da fallo

si el programa ejecuta la sentencia
fail(mensaje explica6vo)

19

ndice
Pruebas: qu es probar?
Cmo hacer pruebas con JUnit
Enfoque de las pruebas
caja negra | caja blanca
cobertura

Algunas Palabras

23

Enfoques
De caja negra
cuando conocemos lo que 6ene que hacer el cdigo
ejercitamos todo lo que 6ene que hacer
pruebas funcionales

De caja blanca
cuando conocemos el cdigo fuente
forzamos la ejecucin de todo el cdigo
pruebas estructurales

24

caja negra

Casos de prueba

Qu hay que probar?

todo lo que dice la especicacin:
manual
instrucciones
otra documentacin

Cobertura del 100%

si va tachando lo que se va probando,
100% es cuando todo est tachado
funcionamiento correcto
deteccin y reporte de errores

25

caja negra

Datos de prueba

Con qu datos se prueba?

1. divida el espacio de datos en clases de equivalencia

clase de equivalencia:
datos que provocan el mismo comportamiento
no parece que deban provocar comportamientos diferentes

2. elija un dato normal de clase de equivalencia

3. pruebe con todos los datos frontera:
valores extremos de la clase de equivalencia

26

caja negra

Datos de prueba

Aada aquellos casos en los que sospeche que el

programador puede haberse equivocado
Pruebe todas las combinaciones
{ datos comportamiento }

27

caja blanca

Casos de prueba

Qu hay que probar?

ejecutar al menos una vez cada sentencia
cobertura de sentencias

ejecutar al menos una vez cada condicin

con resultado cierto y falso
cobertura de ramas

Mtodo
si va tachando el cdigo probado
100% es cuando todo est tachado

28

caja blanca

Casos de prueba

if (...)
si T, si F

switch (...)
cada case + default

cobertura de bucles
for -> 3 pruebas: 0 veces, 1 vez, n>1 veces
repeat -> 2 pruebas: 1 vez, n>1 veces
while -> 3 pruebas: 0 veces, 1 vez, n>1 veces

29

Medidas: cobertura
Cuntas pruebas hay que hacer?
no se puede probar con todos los datos posibles
la cobertura
mide cunta variedad de casos hemos cubierto

En caja negra
casos probados / clases posibles

En caja blanca
lneas probadas / lneas de cdigo
condiciones probadas / opciones en el cdigo
bucles probados / bucles presentes

30

ndice
Pruebas: qu es probar?
Cmo hacer pruebas con JUnit
Enfoque de las pruebas
caja negra | caja blanca
cobertura

Algunas Palabras

31

Palabras nales (1..)

Probar es buscarle los fallos a un programa
Probar requiere pensar mal del programa
y provoca tensiones humanas
el que prueba es como un cliente quisquilloso
que no hace sino buscar razones
para no pagar

Probar es muy costoso en 6empo y esfuerzo

Probar es tedioso
Probar es un arte

32

Palabras nales (..2)

Hacer una buena batera de pruebas
cuesta 6empo y trabajo
ayuda a entender el problema
permite saber cundo hemos acabado
permite repasar todas las pruebas en el futuro

la experiencia demuestra que

a la larga se ahorra 6empo
se reducen los errores en el producto nal

33

Ejemplo de Pruebas Unitarias

Repasando........
Un programa es aceptable cuando:
Hace lo que se acord que deba hacer en las especificaciones.
No hace lo que no debe hacer.

Un programador jams debera entregar un programa sin

haberlo probado. Igualmente, quien recibe un programa de
otro jams debera aceptarlo sin haberlo probado.
Para aprobar una prctica sta debe pasar las pruebas
funcionales.
Cualquier funcionalidad de un programa sin una prueba
automatizada, simplemente no existe (Extreme Programming
Explained, de Kent Beck)

JUNIT. Prueba

Pruebas Unitarias Sistemticas : Conceptos

Prueba unitaria: una prueba individual de un mtodo o clase.
Prueba unitaria ad-hoc: por ejemplo, cuando creamos un objeto de
cierta clase con BlueJ e invocamos manualmente un mtodo del mismo
con distintas entradas para ver si funciona.
Sin embargo, con este tipo de pruebas no se puede trabajar eficiente y
sistemticamente.
Cada vez que cambiamos algo en el mtodo o clase tendramos que
volver a pasar todas las pruebas para asegurarnos de que nada se ha
descabalado. Es decir, realizar pruebas de regresin.
Para ello, vendra muy bien algo que nos permitiera definir
sistemticamente una serie de pruebas y ejecutarlas
automticamente, tantas veces como necesitramos.
JUNIT nos permite hacer esto. JUNIT + BlueJ todava mejor.

Pruebas Unitarias Sistemticas : Procedimiento

Antes de implementar una determinada funcionalidad, piensa cmo
deberas probarla para verificar que se comporta correctamente. Esto
permite desarrollar la funcionalidad teniendo las ideas muy claras de lo
que debera hacer.
Escribe el cdigo que implementa la funcionalidad deseada.
Escribe el cdigo de las pruebas inmediatamente despus.
Ejecuta las pruebas que hiciste.
Corrige la unidad de cdigo que implementa la funcionalidad deseada
hasta que pase todas y cada una de las pruebas.
Al aadir una nueva funcionalidad, repite el ciclo: piensa en cmo
probarla, codifica la funcionalidad, codifica las pruebas, ejecuta todas las
pruebas que hiciste (nuevas y viejas). No sigas hasta que el cdigo pase
absolutamente todas las pruebas.
As una y otra vez para cada nueva funcionalidad que implementes. Lo
vemos con un ejemplo.
JUNIT. Pruebas Unitarias

Ejemplo Procedimiento Prueba con JUNIT (1)

Desarrollar un mtodo esttico que tome un array de enteros como
argumento y devuelva el mayor valor encontrado en el array.
public class MayorNumero {
/**
* Devuelve el elemento de mayor valor de una lista
* @param list Un array de enteros
* @return
El entero de mayor valor de la lista
*/
public static int obt_mayorNumero(int lista[]) {
return 0; // para que compile hasta que desarrollemos el mtodo
}
}

JUNIT. Pruebas Unitarias

Ejemplo Procedimiento Prueba con JUNIT (2)

Qu pruebas se te ocurren para el mtodo obt_mayorNumero?
Qu ocurre para un array con valores cualesquiera (el caso
normal)?
[3, 7, 9, 8] 9
Qu ocurre si el mayor elemento se encuentra al principio, en
medio o al final del array?
[9, 7, 8] 9;
[7, 9, 8] 9;
[7, 8, 9] 9
Y si el mayor elemento se encuentra duplicado en el array?
[9, 7, 9, 8] 9
Y si slo hay un elemento en el array?
[7] 7
Y si el array est compuesto por elementos negativos?
[-4, -6, -7, -22] -4
JUNIT. Pruebas Unitarias

Ejemplo Procedimiento Prueba con JUNIT (3)

Escribimos el cdigo del mtodo obt_mayorNumero:
/**
* Devuelve el elemento de mayor valor de una lista
*
* @param list Un array de enteros
* @return
El entero de mayor valor de la lista
*/
public static int obt_mayorNumero(int lista[]) {
int indice, max = Integer.MAX_VALUE;
for (indice = 0; indice < lista.length-1; indice++) {
if (lista[indice] > max) {
max = lista[indice];
}
}
return max;
}
JUNIT. Pruebas Unitarias

Ejemplo Procedimiento Prueba con JUNIT (4)

Escribimos el cdigo de las pruebas (1):
import junit.framework.*;
public class TestMayorNumero extends TestCase {
public TestMayorNumero() {
}
public void testSimple() {
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {3, 7, 9, 8}));
}
public void testOrden() {
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {9, 7, 8}));
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {7, 9, 8}));
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {7, 8, 9}));
}
// Sigue en la prxima transparencia

JUNIT. Pruebas Unitarias

Ejemplo Procedimiento Prueba con JUNIT (5)

Escribimos el cdigo de las pruebas (2):
// Sigue de la transparencia anterior
public void testDuplicados() {
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {9, 7, 9, 8}));
}
public void testSoloUno() {
assertEquals(7, MayorNumero.obt_mayorNumero(new int[] {7}));
}
public void testTodosNegativos() {
assertEquals(-4, MayorNumero.obt_mayorNumero(new int[] {-4, -6, -7, 22}));
}
} // Fin de la clase

JUNIT. Pruebas Unitarias

Ejemplo Procedimiento Prueba con JUNIT (6)

Ejecutamos las pruebas:

JUNIT. Pruebas Unitarias

10

Ejemplo Procedimiento Prueba con JUNIT (7)

Ejecutamos las pruebas:

JUNIT. Pruebas Unitarias

11

Ejemplo Procedimiento Prueba con JUNIT (8)

Qu est mal?: PREGUNTAR A ALUMNOS
/**
* Devuelve el elemento de mayor valor de una lista
*
* @param list Un array de enteros
* @return
El entero de mayor valor de la lista
*/
public static int obt_mayorNumero(int lista[]) {
int indice, max = Integer.MAX_VALUE;
for (indice = 0; indice < lista.length-1; indice++) {
if (lista[indice] > max) {
max = lista[indice];
}
}
return max;
}
JUNIT. Pruebas Unitarias

12

Ejemplo Procedimiento Prueba con JUNIT (9)

Qu est mal?:
/**
* Devuelve el elemento de mayor valor de una lista
*
* @param list Un array de enteros
* @return
El entero de mayor valor de la lista
*/
public static int obt_mayorNumero(int lista[]) {
int indice, max = Integer.MAX_VALUE;
for (indice = 0; indice < lista.length-1; indice++) {
if (lista[indice] > max) {
max = lista[indice];
}
}
return max;
}

Integer.MIN_VALUE

JUNIT. Pruebas Unitarias

13

Ejemplo Procedimiento Prueba con JUNIT (10)

Volvemos a ejecutar las pruebas (hasta que pasen todas):

JUNIT. Pruebas Unitarias

14

Ejemplo Procedimiento Prueba con JUNIT (11)

Qu est mal?:
Falla en este assert, devuelve el 8 y no el 9

public void testOrden() {

assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {9, 7, 8}));
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {7, 9, 8}));
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {7, 8, 9}));
}

public static int obt_mayorNumero(int lista[]) {

int indice, max = Integer.MAX_VALUE;
for (indice = 0; indice < lista.length-1; indice++) {
if (lista[indice] > max) {
max = lista[indice];
}
PREGUNTAR A ALUMNOS
}
ejemplo de que siempre hay
return max;
que analizar los extremos
}
JUNIT. Pruebas Unitarias

15

Ejemplo Procedimiento Prueba con JUNIT (12)

Qu est mal?:
Falla en este assert, devuelve el 8 y no el 9

public void testOrden() {

assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {9, 7, 8}));
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {7, 9, 8}));
assertEquals(9, MayorNumero.obt_mayorNumero(new int[] {7, 8, 9}));
}
lista.length

public static int obt_mayorNumero(int lista[]) {

int indice, max = Integer.MAX_VALUE;
for (indice = 0; indice < lista.length-1; indice++) {
if (lista[indice] > max) {
max = lista[indice];
}
}
return max;
}
JUNIT. Pruebas Unitarias

16

Ejemplo Procedimiento Prueba con JUNIT (13)

Otra vez a ejecutar las pruebas (ahora ya pasan todas, podemos seguir):

JUNIT. Pruebas Unitarias

17

Ventajas de Probar Progresivamente

Este mtodo puede parecer extremo (casi es Extreme Programming),
pero normalmente ahorra tiempo y esfuerzo:
Si pruebas mientras desarrollas

Si desarrollas todo y al final pruebas

Lo mejor es un trmino medio: cada funcionalidad significativa que

desarrolles prubala antes de seguir.
JUNIT. Pruebas Unitarias

18

Pruebas con JUNIT: Explicacin Formal (1)

Marco para desarrollar pruebas unitarias (1)
lnea 1
lnea 3
lnea 10
lnea 15
-

import junit.framework.*;
public class Pruebas extends TestCase {
// variables_privadas
public Pruebas ( ) {
// inicializacin
}
public void testXXX ( ) {
// cdigo para verificar que el mtodo a probar funciona correctamente
}
public static void main (String[ ] args) {
junit.textui.TestRunner.run(Pruebas.class); // ejecucin consola texto
// junit.swingui.TestRunner.run(Pruebas.class); // ejecucin ventana
}
} // fin de clase

JUNIT. Pruebas Unitarias

19

Pruebas con JUNIT: Explicacin Formal (2)

Marco para desarrollar pruebas unitarias (2):
a) (lnea 1). Importar las clases de JUNIT necesarias.
b) (lnea 3). Toda clase que contenga pruebas ha de heredar de la clase
TestCase. sta contiene la mayora de funcionalidad necesaria para
realizar pruebas, incluyendo los assert.
c) (lnea 10). Todo mtodo que empiece por test en la clase ser
ejecutado automticamente por JUNIT. As han de empezar todos
los mtodos con casos de prueba.
Otros detalles:
a) Cada mtodo que slo trate un caso o aspecto a probar.
b) (lnea 15). Si no usas BlueJ puedes ejecutar las pruebas por consola.

JUNIT. Pruebas Unitarias

20

10

Herramientas para Pruebas

PHPUnit
JUnitPerf
HttpUnit

JWebUnit
JFCUnit
Jester

Cactus
JXUnit
JUnit

Su uso depende en su mayoria del lenguaje de programacin sobre el

cual se trabaja.

JUNIT. Pruebas Unitarias

27

14