Testing de Sistemas OO

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

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

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

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

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

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

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

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?

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)

10. ¿Qué Factores Inciden al Testear un Método? IUT – Implementation Under Test

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)

12. Diagrama de Estados para una Clase • Tener diagramas de estado de las clases a testear para verificar la correcta transición entre estados

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

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

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

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

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

18. Ejemplo 1 (1)

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.

20. Ejemplo 1 (3) Plantilla de test para m1 Salidas Entradas

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

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

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)

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

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.

26. Ejemplo 2 – Pila (Criterios Casos de Prueba) • Criterios Size • Criterios isEmpty

27. Ejemplo 2 – Pila (Criterios Casos de Prueba) • Criterios Push(e) • Criterios get

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

29. 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);

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

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?

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?

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

34. Ejemplo 2 – Pila (Prueba 3) pila.push(x); pila.push(y); size = pila.size(); sizeEsperado = 2; junit.framework.Assert.assertEquals(size, sizeEsperado);

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

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é

37. Ejemplo 2 – Pila (Prueba 4, Prueba y Código5) vacio = pila.isEmpty(); vacioEsperado = false; junit.framework.Assert.assertEquals(vacio, vacioEsperado); Corrí las pruebas sin cambiar el código y pasó. 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; } Se agregó este método en la clase CuerpoPila

38. Ejemplo 2 – Pila (Prueba y Código 6) size = pila.size(); sizeEsperado = 0; junit.framework.Assert.assertEquals(size, sizeEsperado); 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 public Object get(){ Object elemento = laPila.getElemento(); laPila = laPila.getSiguiente(); size--; return elemento; }

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ó.

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

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ó

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)

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

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

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

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

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

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

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