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 siguiente |