1 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
2 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
3 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
4 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
5 ¿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
6 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
7 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?
8 ¿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)
9 ¿Qué Factores Inciden al Testear un Método? IUT – Implementation Under Test
10 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)
11 Diagrama de Estados para una Clase Tener diagramas de estado de las clases a testear para verificar la correcta transición entre estados
12 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
| Página siguiente |