Testing de Sistemas OO Grupo de Ingeniería de Software (Gris) Facultad de Ingeniería Universidad de la República

Gris 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 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 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 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 ¿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 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ónCaso 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 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 ¿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 ¿Qué Factores Inciden al Testear un Método? IUT – Implementation Under Test

Gris 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 Diagrama de Estados para una Clase Tener diagramas de estado de las clases a testear para verificar la correcta transición entre estados

Gris 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 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 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 ¿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 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 Ejemplo 1 (1)

Gris 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 Ejemplo 1 (3) zbcdazbcd C11z1b1c1d2a2z1b1c2d C21z1b1c2d…………… C31z1b1c3d…………… C41z1b2c1d…………… ………………………… Plantilla de test para m1 Entradas Salidas

Gris 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 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 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 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 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 Ejemplo 2 – Pila (Criterios Casos de Prueba) Criterios Size PilaResultado Esperado Pila cualquieraCant. de Elementos Criterios isEmpty PilaResultado Esperado Vacíatrue No vacíafalse

Gris Ejemplo 2 – Pila (Criterios Casos de Prueba) Criterios Push(e) PilaResultado Esperado CualquieraPila con un elemento más y ese elemento es “e”. Este elemento es el siguiente a “sacar” Criterios get PilaResultado Esperado No vacíaÚltimo elemento al que se hizo push. El tamaño es uno menos al tamaño anterior.

Gris 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

Gris 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(); AssertEqual(z,x); size = p.size(); sizeEsperado = 0; AssertEqual(size, sizeEsperado); vacio = p.isEmpty(); vacioEsperado = true; AssertEqual(vacio, vacioEsperado);

Gris 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 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 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 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 Ejemplo 2 – Pila (Prueba 3) pila.push(x); pila.push(y); size = pila.size(); sizeEsperado = 2; junit.framework.Assert.assertEquals(size, sizeEsperado);

Gris 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 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 Ejemplo 2 – Pila (Prueba 4, Prueba y Código5) vacio = pila.isEmpty(); vacioEsperado = false; junit.framework.Assert.assertEquals(vacio, vacioEsperado); 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 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 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 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 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 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 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 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 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 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 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 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 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