13
Distintos Tipos de Cubrimiento
Cubrimiento basado en el diagrama de estados
Transiciones cubiertas y otros (mirar el diagrama de estados como el flujo de control visto en IIS)
Cubrimiento basado en pre y post condiciones
Cuantas de estas son cubiertas para cada método
Cubrimiento basado en el código
Esto ya lo vimos en IIS
Cubrimientos basados en el diagrama de estados ampliado con los métodos de la clase (Binder)
Normalmente son muy complejos
14
Otro Concepto Básico
La correcta colaboración (o interacción) entre los objetos de un programa es CRÍTICA para la correctitud del programa
Esto se vio en IIS. Un objeto que cumple correctamente con su funcionalidad puede ser "mal usado" debido a problemas de integración
Incluso puede ser usado correctamente pero no funcionar correctamente en el nuevo contexto (Weyuker) ¿Recuerdan?
Recordar que la integración en OO es muy distinta a la de lenguajes procedurales
15
¿Dónde Obtenemos las Interacciones?
Diagramas de clases
Diagramas de interacción
Diagramas de colaboración
Otros lugares
Seguimos usando las pre y post condiciones de cada método y los diagramas de estado para realizar los casos de prueba
16
Tipos de Interacciones
Clase de Colección
Guarda instancias de alguna clase pero no interactúa con ninguna de ellas (Ej: clase Vector de Java)
Un ejemplo es la clase Pila
Clase Colaboradora
Clase que sí utiliza directamente a instancias de otras clases
En definitiva son las clases que no clasifican como Clase de Colección
17
Ejemplo 1 (1)
18
Ejemplo 1 (2)
Quiero testear el método m1
Creo una clase TestZ que extiende TestCase
Considero los distintos estados en los cuales puede estar z
Considero los estados de b y c
Considero el resultado a
Quizás deba considerar el estado de d (depende de si cambios en el estado de d pueden no incidir en el estado de z)
Supongamos lo siguiente:
Todos los objetos tienen dos estados 1 y 2 menos d que tiene 3 estados, 1, 2 y 3.
19
Ejemplo 1 (3)
Plantilla de test para m1
Entradas
Salidas
20
Ejemplo 1 (4)
No todos las combinaciones de casos son posibles
Tengo que identificar cuales no son posibles, ya que quizás muchas combinaciones de estado no se puedan dar
Al testear no solo me voy a fijar en el resultado devuelto (el objeto a), sino que voy a controlar los otros resultados esperados (por ejemplo un cambio de estado en z)
En el ejemplo b no cambia ya que es solo de entrada por definición del método m1, se puede sacar de la planilla de la parte de resultados (reduce el número de casos posibles). Pero hay que testear que b no cambia al ejecutar el método
21
Ejemplo 1 (5)
Las pre y post condiciones del método también eliminan casos posibles de la tabla
Siempre que pueda intento probar con los "límites" o bordes como vimos en IIS
Estoy usando caja negra ¿se dan cuenta?
Después de ejecutado el test veo si cumplí con el criterio de cubrimiento establecido.
Es bueno tener estas pruebas de los métodos dentro de una prueba de ciclo en el diagrama de estados de la clase que se está probando
De esta manera no se repiten las pruebas
Vemos un ejemplo sencillo más adelante. Los difíciles los van a hacer ustedes
22
Clusters y Heads
Class Cluster (Grupos de Clases)
Grupo de clases relacionadas
Small Class Cluster (Pequeño Grupo de Clases)
Es un grupo que incluye varias clases que están tan fuertemente acopladas que el testing en aislamiento de los constituyentes del grupo no es práctico
Cluster Head (Cabeza del Grupo)
Una clase que usa las otras clases (del cluster) como variables de instancia o como parámetros de los mensajes
Un SCC puede ser tratado como una única clase si:
La cabeza del grupo usa todas las capacidades de los constituyentes y
si los constituyentes no son usados fuera del cluster (a menos de la creación)
23
Clusters, Heads y Alcance del Testeo de Clases
Un SCC puede resultar también de relaciones cíclicas entre clases. Estas clases normalmente no tiene sentido probarlas en aislamiento.
Las estrategias que se describieron pueden ser aplicadas al cluster head (si el cluster se puede tratar como una clase individual)
Es por esto último que las clases individuales y los SCC son el foco del testeo unitario a nivel de clases
24
Ejemplo 2 – Pila (Pre y Post Condiciones)
size
Pre – True
Post – Devuelve la cantidad de elementos que tiene la pila
isEmpty
Pre – True
Post – Devuelve true en caso que la pila no tenga elementos y false en caso contrario
push(e)
Pre – True
Post – Agrego en la pila el elemento e. Queda como primero a ser extraido mediante get. Aumenta la cantidad de elementos en 1.
get()
Pre – size() > 1
Post – Devuelvo el último elemento al que se le hizo push. Decrementa en uno la cantidad de elementos.
25
Ejemplo 2 – Pila (Criterios Casos de Prueba)
Criterios Size
Criterios isEmpty
26
Ejemplo 2 – Pila (Criterios Casos de Prueba)
Criterios Push(e)
Criterios get
27
Ejemplo 2 – Pila (Diagrama de Estados)
A partir del diagrama de estados puedo definir criterios de cubrimientos similares a los vistos en el curso de IIS
Diagramas de estado modificado
28
Ejemplo 2 – Pila (Cubrir las Ramas)
int sizeEsperado; bool vacioEsperado; int size; bool vacio;
Element x = new Element(); y = new Element(); Element z = null
p = new Pila();
size = p.size(); sizeEsperado = 0;
AssertEqual(size, sizeEsperado);
vacio = p.isEmpty(); vacioEsperado = true;
AssertEqual(vacio, vacioEsperado);
p.push(x);
p.push(y);
size = p.size(); sizeEsperado = 2;
AssertEqual(size, sizeEsperado);
vacio = p.isEmpty(); vacioEsperado = false;
AssertEqual(vacio, vacioEsperado);
z = p.get(); z = p.get();
AssertEqual(z,x);
size = p.size(); sizeEsperado = 0;
AssertEqual(size, sizeEsperado);
vacio = p.isEmpty(); vacioEsperado = true;
AssertEqual(vacio, vacioEsperado);
29
Ejemplo 2 – Pila (Una Forma de Trabajo)
Símil TDD (Test-Driven Development)
Me voy a basar en la especificación para construir cada método pero lo voy a construir después de codificar cada prueba
Luego de armada la prueba construyo el código y corro la prueba hasta que pase
Así voy iterando
No vamos a ver TDD
30
Ejemplo 2 – Pila (Prueba 1)
int sizeEsperado;
boolean vacioEsperado;
int size;
boolean vacio;
Pila pila = null;
Integer x = new Integer(1);
Integer y = new Integer(2);
Integer z = null;
pila = new Pila();
size = pila.size();
sizeEsperado = 0;
junit.framework.Assert.assertEquals(size, sizeEsperado);
Lo que hice fue cortar y pegar las seudo-pruebas en un IDE e ir armando de a una, después codificaba lo necesario para pasar esa prueba.
Los objetos que guardo en la pila son instancias de la clase Integer. ¿Esto influye en las pruebas? ¿Debo probar con otras clases?
31
Ejemplo 2 – Pila (Código 1)
public class Pila {
int size;
public Pila() {
size = 0;
}
public int size(){
return size;
}
}
Tengo especificado el método size(), este método según su especificación devuelve el tamaño de la pila. Para pasar el primer test solo debo inicializar size en cero y devolver este valor.
También podría no querer usar una variable size pero si algo es importante es codificar sencillo.
¿Qué pasa si no defino la variable size? ¿Qué pasa si al crear la pila no inicializaba size y en el método size() hacía return 0?
32
Ejemplo 2 – Pila (Prueba y Código 2)
vacio = pila.isEmpty();
vacioEsperado = true;
junit.framework.Assert.assertEquals(vacio, vacioEsperado);
public class Pila {
int size;
public Pila() {
size = 0;
}
public int size(){
return size;
}
public boolean isEmpty(){
return (size == 0);
}
33
Ejemplo 2 – Pila (Prueba 3)
pila.push(x);
pila.push(y);
size = pila.size();
sizeEsperado = 2;
junit.framework.Assert.assertEquals(size, sizeEsperado);
34
Ejemplo 2 – Pila (Código 3)
public class Pila {
int size;
CuerpoPila laPila;
public Pila() {
size = 0;
laPila = null;
}
public int size(){
return size;
}
public boolean isEmpty(){
return (size == 0);
}
public void push(Object elemento){
CuerpoPila aux = new CuerpoPila(elemento, laPila);
laPila = aux;
size++;
}
}
35
Ejemplo 2 – Pila (Código 3 cont.)
public class CuerpoPila {
CuerpoPila siguiente;
Object elemento;
public CuerpoPila(Object elem, CuerpoPila sig) {
elemento = elem;
siguiente = sig;
}
public Object getElemento(){
return elemento;
}
}
Todavía no era necesario hacer el método getElemento pero me apuré
36
Ejemplo 2 – Pila (Prueba 4, Prueba y Código5)
vacio = pila.isEmpty();
vacioEsperado = false;
junit.framework.Assert.assertEquals(vacio, vacioEsperado);
z = (Integer)pila.get();
z = (Integer)pila.get();
junit.framework.Assert.assertEquals(z,x);
public Object get(){
Object elemento = laPila.getElemento();
laPila = laPila.getSiguiente();
return elemento;
}
Corrí las pruebas sin cambiar el código y pasó.
Se agregó este método en la clase CuerpoPila
37
Ejemplo 2 – Pila (Prueba y Código 6)
size = pila.size();
sizeEsperado = 0;
junit.framework.Assert.assertEquals(size, sizeEsperado);
public Object get(){
Object elemento = laPila.getElemento();
laPila = laPila.getSiguiente();
size–;
return elemento; }
Corrí las pruebas sin cambiar el código y falló.
Faltaba decrementar el tamaño de la pila
Esto tendría que haber sido considerado antes ya que la funcionalidad de get especificaba el decremento del tamaño de la pila
Si solo miraba la prueba a pasar estaba bien no considerarlo
38
Ejemplo 2 – Pila (Prueba Extra)
Si la programación fuese defensiva debería de tener un caso de prueba en el que hago get cuando la pila está vacía
Esto debería devolver, por ejemplo una excepción
También sería correcto que esta posibilidad estuviera en el diagrama de estados de la clase
39
Ejemplo 2 – Pila (Comentarios)
Es un ejemplo sencillo
Bastaba con tener un único ciclo para cubrir una cantidad grande de posibilidades (esto es debido al diagrama de estados de la clase)
Se aprovechó este ciclo para cubrir los casos derivados de las pre y post condiciones de cada método ¿se dieron cuenta? Es decir, no se agregan test para algún caso particular de ninguno de los métodos
Debido al tipo de interacción nunca importó el estado de los elementos a los cuales se les hace push. La tabla de estados era trivial y por eso no se usó
40
Recomendaciones para el PIS (1)
¿Qué clases testear?
Detectar SCC y CH (esto ayuda a no testear absolutamente todas las clases) La "S" es de small, no se pasen de granularidad
No testear con JUnit ninguna de las clases relacionadas con las GUI
Definir cuál es la unidad para los implementadores y cuál para los verificadores (nivel de granularidad)
41
Recomendaciones para el PIS (2)
¿Cómo testear las clases?
Pueden generar las clases de test a partir de su especificación (métodos y diagramas de estado).
Pueden generar las clases de test y que estas sean la propia especificación
Tratar de usar una estrategia bottom-up siempre que sea posible
No testear los métodos get y set de las clases
Tener una clase TestAll y ejecutarla en mojones definidos
Por ejemplo cada vez que se realiza la integración global
TestAll corre todos los casos de prueba de forma automática
42
Recomendaciones para el PIS (3)
¿Cómo testear las clases?
Se recomienda no construir las pruebas a partir del código (solo utilizarlo cuando no alcanzo el cubrimiento establecido). Pruebas funcionales de caja negra
En caso de no alcanzar el cubrimiento establecido entonces utilizo el código para obtener datos de prueba
Las pruebas de caja negra deberían ser suficientes para alcanzar cubrimiento de decisión
Se recomienda usar la técnica de valores límites que se estudió en IIS
43
Recomendaciones para el PIS (3)
¿Cómo testear las clases?
Chequear el estado esperado
Tener métodos que devuelvan si el objeto está en cierto estado o no. Ejemplo: isStateXX();
No está mal considerar que estos métodos son correctos. Es decir, no testearlos explícitamente
No "revisar" el estado de los miembros de la clase bajo test a menos de entenderlo muy necesario (por ejemplo para saber en que estado está la clase bajo test)
Esto reduce la tabla de entradas y salidas
Estoy considerando que estas clases ya fueron testeadas individualmente y que es normal que el estado de la clase bajo test se desprenda directamente del estado de sus miembros
44
Recomendaciones para el PIS (4)
Sobre los criterios de cubrimiento
Definir el criterio de cubrimiento, a nivel de métodos y a nivel de clase
Mínimo a nivel de métodos: Cubrimiento de sentencias para cada clase a testear (a nivel de cada método)
Puede ser adecuado cubrimiento de decisión. Este se debería desprender por si solo a partir de pruebas funcionales de caja negra. Hansel es más exigente (a riesgo del consumidor)
No agregar test a mi suite que no mejoren mi capacidad en descubrir fallas (me puedo basar en el cubrimiento)
Si derivamos los casos de prueba de las pre y post condiciones de cada método, deberíamos cumplir con el criterio de decisión
45
Recomendaciones para el PIS (5)
Sobre los criterios de cubrimiento
Cubrir todos los arcos del diagrama de estados de la clase bajo test. Otros criterios de cubrimiento pueden ser usados pero la test suite va a ser más compleja de armar
Realizar asserts en puntos particulares del recorrido de las ramas, como lo vimos en el ejemplo de la pila.
Hacerlo de forma razonable para testear el comportamiento de la clase. Es decir, testear interacciones de métodos y no solo métodos en aislamiento
Cubrimiento a nivel de funcionalidad de los métodos y de las clases
Hacerlo de forma razonable para testear la funcionalidad de la clase y no solo de los métodos de forma individual
Para esto usar el diagrama de estados de la clase
46
Recomendaciones para el PIS (6)
Sobre el testing de los verificadores
Buscar un nivel de granularidad interesante para el testeo unitario
Puede ser bueno testear las clases que "controlan" los casos de uso
También puede ser complejo
Testear a "pedal" la funcionalidad de los casos de uso y los ciclos funcionales utilizando las GUI
Si saben usar herramientas automáticas para estos casos las pueden utilizar
Este es el testing de mayor importancia para los verificadores
47
Recomendaciones para el PIS (7)
Mantener las clases y el diseño sencillos
Esto se puede ver desde el punto de vista del test realizando la siguiente pregunta "¿Cuánto me cuesta testear esta clase?"
La creación temprana de casos de prueba puede detectar malos diseños
 Página anterior | Volver al principio del trabajo | Página siguiente  |