Pruebas Orientadas A Objetos

Pruebas Orientadas a Objetos
Para probar adecuadamente los sistemas OO, deben hacerse tres cosas:1.La definición de las pruebas debe ampliarse para incluir técnicas de detección de erroresaplicados a los modelos de DOO y AOO2.La estrategia para las pruebas de unidad e integración deben cambiar significativamente3.El diseño de casos de prueba debe tener en cuenta las características propias delsoftwareorientado a objetos.
22.1. AMPLIANDO LA VISIÓN DE LA REALIZACIÓN DE LA PRUEBA
Un problema en la definición de atributos de clases no descubierto durante el análisis provocaráefectos colaterales que pudieran ocurrir si el problema no se descubriera hasta el diseño ocodificación (o incluso hasta la próxima iteración del análisis).Si el problema permanece sin detectar durante el diseño y sepasa a la actividad de codificación, serealizará un esfuerzo y desgaste de energía considerable para generar el código que implemente unatributo innecesario.Durante las etapas posteriores de su desarrollo, los modelos de AOO y DOO proporcionaninformación sustancial acerca de la estructura y comportamiento del sistema. Por esta razón, estosmodelos deberán ser sometidos a una revisión rigurosa,previa a la generación de código.Todos los modelos orientados a objetos deberán probar su corrección (exactitud), compleción yconsistencia dentro del contexto de la sintaxis del modelo, semántica y pragmática.
22.2. MODELOS DE PRUEBAS AOO Y DOO
Los modelos de análisis y diseño no pueden probarse en el sentido convencional, pues no puedenejecutarse. Sin embargo, pueden usarse las revisiones técnicasformales para examinar la corrección(exactitud) y consistencia de ambos modelos.
22.2.1. CORRECCIÓN (EXACTITUD) DE LOS MODELOS DE AOO Y DOO
La notación y sintaxis usada para representar los modelos de análisis y diseño estará vinculada elmétodo específico de análisis y diseño elegidos para el proyecto.Para determinar si el modelo realmente refleja el mundo real, deberá ser presentado a losexpertosdel dominio, quienes examinarán las definiciones de clases y jerarquías en busca de omisiones yambigüedades. Se evalúan las relaciones de clases (conexiones de instancias) para determinar sireflejan exactamente las conexiones de objetos del mundo real.
22.2.2. CONSISTENCIA DE LOS MODELOS DE AOO Y DOO
La consistencia de los modelos de AOO y DOO pueden juzgarse a través de una “consideracióndelas relaciones entre entidades en el modelo. Un modelo inconsistente tiene representaciones que por una parte no son correctamente reflejadas en otras partes del modelo”.Para valorar la consistencia, deberán examinarse cada clase y sus conexiones a otras clases. Puedeusarse el modelo clase-responsabilidad-colaboración (CRC) y un diagrama de objeto-relación parafacilitar esta actividad.El modeloobjeto-relación aporta una representación gráfica de las conexiones entre clases.
22.3. ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS
La estrategia clásica para ejecutar pruebas sobre software de computadora comienza con la “pruebaa pequeña escala” y trabaja moviéndose hacia la “prueba a gran escala”. Comenzamos con la pruebade unidad, y culminamos con la de validación y prueba del sistema.22.3.1. PRUEBA DE UNIDAD EN EL CONTEXTO OO
Al considerar el software orientado a objetos, cambia el concepto de unidad. En vez de módulosindividuales, la menor unidad a probar es la clase y objeto encapsulado. No podemos probar con detalle una operación aisladamente sino como parte de una clase.
1

CAPÍTULO 22 PRUEBAS ORIENTADAS A OBJETOS



A diferencia de la prueba de unidad del softwareconvencional, el cual tiende a centrarse en eldetalle algorítmico de un módulo y los datos que fluyen a lo largo de la interfaz de este,
la
pruebade clase

para software OO está dirigido por las operaciones encapsuladas por la clase y el estado delcomportamiento de la clase.
22.3.2. PRUEBA DE INTEGRACIÓN EN EL CONTEXTO OO
Debido a que el software orientado a objetos no tiene una estructura...