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 |