Testing de Sistemas OO

Grupo de Ingeniería de Software (Gris)Facultad de IngenieríaUniversidad de la República

Gris - 2003 2

Friedman y Voas Que extraño es decir que testear un programa

y que nunca resulte en una falla es un problema, pero de hecho, es eso exactamente lo que estamos diciendo.

Friedman y Voas

¿Y que pasa en el PIS?• A mi entender las fallas detectadas son pocas

comparado con las que realmente existen en los productos realizados

Gris - 2003 3

Algunas Diferencias Ningún método es una isla

• Cada método debe ser testeado en el contexto de su clase y sus características heredadas

Los objetos preservan un estado• Debemos testear buscando faltas que pueden

aparecer en alguna secuencia de mensajes y estados pero no en otras

Los objetos guardan secretos• Nos basamos en los métodos de la clase para

reportar los resultados del test o encontramos otra forma

Gris - 2003 4

Algunas Diferencias (2) Considerando las diferencias:

• Los mensajes es la forma de comunicarse con las clases así que debo testear a nivel de métodos. Esto es similar a lo visto en IIS. La diferencia es que estos métodos pueden recibir como parámetros otros objetos o al ejecutarse llamar a otros métodos

• Tengo que tener en cuenta los estados posibles de un objeto para generar los casos de prueba

• Existen otros criterios de cubrimiento además de los ya vistos (por ejemplo, cubrimiento usando los caminos del diagrama de estados de una clase - Ejecución de secuencias de métodos)

• Nos basamos en los métodos de la clase para reportar su estado

Gris - 2003 5

Testing de Clases Básicas Objetos que no usan otros objetos Visto en el curso de IIS Normalmente son las más fáciles de testear

IMPORTANTE: Se tiene una especificación de los métodos de la clase y de la clase: formal, semi-formal, lenguaje natural, diagrama de estados, etc. O las pruebas son la propia especificación pero en este caso hay que hacerlas antes de implementar la clase o en paralelo (sino trampa al solitario)• Esto es para cualquier clase y no solo para las

básicas

Gris - 2003 6

¿Cuáles Clases Testear? Decidir que clases testear como una unidad y

cuales como parte de una componente del sistema• A tener en cuenta:

El rol de la clase en el sistema. Riesgo asociado a la clase La complejidad de la clase medida en términos de estados,

operaciones y asociaciones con otras clases El esfuerzo asociado para crear un test driver para la clase El esfuerzo en crear stubs (en caso que sea necesario)

Los Class Cluster (se verá más adelante) pueden ayudar a reducir de forma adecuada la cantidad de test• De forma adecuada – se refiere a reducir la

cantidad de test sin reducir su eficacia

Gris - 2003 7

Pre y Post Condiciones para Especificar Métodos

Tener Pre y Post condiciones de cada método de la clase a testear y derivar los casos de prueba a partir de estos

Tabla similar para las post-condiciones. Similar a lo visto en IIS

Pre-condición Caso de prueba

true (true, Post)

Pre1 (Pre1, Post)(not Pre1, Exception)

not Pre1 (not Pre1, Post)(Pre1, Exception)

Pre1 and Pre2 (Pre1 and Pre2, Post)(Not Pre1 and Pre2, Exception)(Pre1 and not Pre2, Exception)(not Pre1 and not Pre2, Exception)

Gris - 2003 8

Pre y Post Condiciones para Especificar Métodos

Hay que saber si la programación es defensiva o si se está usando diseño por contrato

Estas dos formas de programación o diseño indican distintas formas de testear las clases a partir de las pre y post condiciones

Si uso programación defensiva tengo que testear la clase violando las pre-condiciones y esperando respuestas adecuadas, tales como excepciones

Si uso diseño por contrato no tiene interés generar casos de prueba que violen las precondiciones. De todas maneras tengo que agregar casos de prueba para todas las clases que utilicen otra y ver que nunca se llama a un método sin cumplir las pre-condiciones

¿Qué se consideró en el cuadro anterior?

Gris - 2003 9

¿Qué Factores Inciden al Testear un Método?

El estado del objeto bajo test

Los parámetros pasados en el método y su estado

El resultado esperado

El estado de los objetos a los cuales se les va a pasar un mensaje debido al método que se está testeando (esto es porque el obj. bajo test puede tener igual estado con miembros en distintos estado)

Gris - 2003 10

¿Qué Factores Inciden al Testear un Método?

IUT – Implementation Under Test

TestIUT IUT

Object1Esta clase hereda de TestCase

Res:m1(Par1,Par2)

m2

Object2

m2

Me interesa el resultado, y tanto los parámetros como el estadode los mismos ya que estos pueden ser objetos.

Puede llegar a interesar el estado de los objetos a los que se lesmanda mensajes a causa del mensaje inicial.Suponemos testeados individualmente estos dos objetos.Estoy haciendo Botton-Up

Gris - 2003 11

Aclaraciones Sobre el Supuesto Se supone que los objetos object1 y object2 ya

fueron testeados• Este supuesto se debe entender dentro del proceso

que están siguiendo. En nuestro caso iterativo e incremental

• Estas clases están testeadas considerando la funcionalidad que deben tener en la iteración, es decir, está testeada hasta el punto que está implementada

No en todo momento tengo por que trabajar bottom-up, esto es algo que debe decidir cada grupo• Hay veces que es conveniente usar stubs

Inclusive cuando estoy trabajando bottom-up. Un caso es cuando el setUp de la clase JUnit se complica. Esto además es una alerta puede servir para detectar diseños con mucho acoplamiento (TDD)

Gris - 2003 12

Diagrama de Estados para una Clase Tener diagramas de estado de las clases a testear

para verificar la correcta transición entre estados

Vacio No Vacio

Pila

push(e)

isEmpty() size()

push(e)get() [size>1]

get() [size=1]

Gris - 2003 13

Derivando Casos de Prueba a Partir de D.E. Casos de prueba del diagrama de estados Considero un único constructor por simplicidad Identificar al menos:

• El camino más largo o amplio desde el inicio hasta el final

• Identificar caminos desde el inicio al final que puedan llevar a estados corruptos

• Identificar caminos desde el inicio hasta el fin que puedan causar problemas de performance

• Identificar caminos que pueden ser de interés debido a la funcionalidad que debe cumplir la clase

Estos casos de prueba llevan a ejecutar varios métodos de una clase en forma secuencial

Gris - 2003 14

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

Gris - 2003 15

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

Gris - 2003 16

¿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

Gris - 2003 17

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

Gris - 2003 18

Ejemplo 1 (1)

z

d

b

c

M2

m3

m4

a:=m1(b, c)

+m1(in b : B, inout c : C) : A

-d : D

Z

Gris - 2003 19

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.

Gris - 2003 20

Ejemplo 1 (3)

z b c d a z b c d

C1 1z 1b 1c 1d 2a 2z 1b 1c 2d

C2 1z 1b 1c 2d … … … … …

C3 1z 1b 1c 3d … … … … …

C4 1z 1b 2c 1d … … … … …

… … … … … … … … … …

Plantilla de test para m1

Entradas Salidas

Gris - 2003 21

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

Gris - 2003 22

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

Gris - 2003 23

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)

Gris - 2003 24

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

Gris - 2003 25

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.

Gris - 2003 26

Ejemplo 2 – Pila (Criterios Casos de Prueba) Criterios Size

Pila Resultado Esperado

Pila cualquiera Cant. de Elementos

Criterios isEmpty

Pila Resultado Esperado

Vacía true

No vacía false

Gris - 2003 27

Ejemplo 2 – Pila (Criterios Casos de Prueba) Criterios Push(e)

Pila Resultado Esperado

Cualquiera Pila con un elemento más y ese elemento es “e”. Este elemento es el siguiente a “sacar”

Criterios get

Pila Resultado Esperado

No vacía Último elemento al que se hizo push. El tamaño es uno menos al tamaño anterior.

Gris - 2003 28

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

Vacio No Vaciopush(e)size()

isEmpty()

push(e)get() [size>1]

get() [size=1]

size()

isEmpty()

Gris - 2003 29

Ejemplo 2 – Pila (Cubrir las Ramas)int sizeEsperado; bool vacioEsperado; int size; bool vacio;

Element x = new Element(); y = new Element(); Element z = nullp = 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);

Gris - 2003 30

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

Gris - 2003 31

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?

Gris - 2003 32

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?

Gris - 2003 33

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); }

Gris - 2003 34

Ejemplo 2 – Pila (Prueba 3)

pila.push(x);

pila.push(y); size = pila.size(); sizeEsperado = 2; junit.framework.Assert.assertEquals(size, sizeEsperado);

Gris - 2003 35

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++; } }

Gris - 2003 36

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é

Gris - 2003 37

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

Gris - 2003 38

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

Gris - 2003 39

Ejemplo 2 – Pila (Prueba 7) vacio = pila.isEmpty(); vacioEsperado = true; junit.framework.Assert.assertEquals(vacio, vacioEsperado);

Corrí las pruebas sin cambiar el código y pasó.

Gris - 2003 40

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

Gris - 2003 41

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ó

Gris - 2003 42

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)

Gris - 2003 43

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

Gris - 2003 44

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

Gris - 2003 45

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

Gris - 2003 46

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

Gris - 2003 47

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

Gris - 2003 48

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

Gris - 2003 49

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