Mastery 12: Testeo basado en O.O.

Es bien sabido que desde el inicio de nuestro semestre en la materia de análisis y diseño de desarrollo de software, nos hemos basado principalmente en el paradigma de programación orientado a objetos, por lo que esta entrada no debería ser la excepción, al contrario, se vuelve muy importante dejar en claro algunos nuevos conceptos por aquí.

En esta ocasión hablaremos de cómo poner a prueba nuestras invenciones basadas en la programación O.O. así que, vamos a comenzar.

Bien sabemos que una vez que hemos recorrido el extenso camino del análisis, el diseño, la codificación de un sistema; es importante tener una manera de verificar que nuestra aplicación funcione correctamente, esto es, el testing. (Hablamos a detalle de esto en nuestra mastery 11, validación y verificación de SW).

Eso fue de manera general, pero, ¿qué ocurre en los sistemas basados en la programación de objetos? ¿funciona igual? Pues, más o menos. Verás, los conceptos de testing vistos previamente son, en efecto, los mismos, pero con leves modificaciones.

Vamos a recordar primero la definición de pruebas de software, para asegurarnos que estamos todos en el mismo hilo.

Las pruebas de software se definen como las investigaciones empíricas y técnicas que tienen como objetivo el proporcionar información objetiva e independiente sobre la calidad de determinado producto o sistema. Básicamente es un sistema de control encargado de asegurar la calidad del software que se esta desarrollando, para así garantizar la satisfacción del cliente. (Wikipedia – Pruebas de Software).

La idea de realizar pruebas de software esta basada principalmente en la filosofía de detectar errores en cualquier etapa del proceso de desarrollo, desde el análisis hasta en la interacción directa con el usuario. En el siguiente gráfico intentaré explicar porqué son importantes todas estas aclaraciones.

Como puedes ver en la imagen, durante todo el proceso de análisis, diseño y desarrollo de software existen maneras de probar que lo que estemos haciendo sea correcto. Desde pruebas de requerimientos a través de casos de uso o bien, en relación directa a través de pruebas de aceptación de usuario.

Ahora que ha quedado claro la importancia de las pruebas de testing, es momento de decir cómo diablos probamos nuestro software asumiendo que nos encontramos en la etapa de prueba de código, es decir, la número 4 en la imagen superior.

Pues bueno, en los sistemas de software, la principal diferencia a la hora de hacer pruebas basadas en objetos es justamente poner a prueba los objetos, o también conocidas, clases.

En POO, las clases son la unidad fundamental del sistema, cada clase es por sí misma, un objeto, con atributos, funciones y lo más importante, estados.

Gracias a las clases, un sistema puede dividirse en muchas partes, permitiendo a los encargados de pruebas el someter a análisis todas las clases de un sistema de manera individual o bien, integradas entre sí.

Partiendo de las clases, podríamos clasificar las pruebas en tres tipos diferentes:

This image describes the various levels and techniques of object oriented testing in software testing. — Fotografía extraída de: minigranth.com

El equivalente a pruebas unitarias sería por supuesto, las pruebas de clases, en ellas todas las clases se someten a pruebas para encontrar posibles errores, se analiza que los atributos estén implementados y sean utilizados correctamente, que todos los métodos sean utilizados en algún momento del funcionamiento del sistema y por último, se revisan también las interfaces en caso de ser necesitadas.

Las pruebas de integración o «pruebas de inter-class» involucran el someter a prueba ciertos subsistemas o módulos del todo. Es decir, la colaboración que exista entre clases, que funcionen correctamente y su complementación haya sido dada de manera exitosa.

Por último, las pruebas de sistema, en ellas, se revisa al sistema como un todo, se pone a prueba bajo técnicas específicas basadas en los requerimientos del mismo sistema, poniendo especial atención a que pueda cumplir con todos ellos de manera correcta.

Una herramienta fundamental en las pruebas de sistema son los casos de prueba. Como mencionamos previamente los casos de prueba se pueden diseñar basados en pruebas de clases o en pruebas de integración.

Diseño de casos de prueba unitarias.

Para empezar, la clase debe ser la unidad más pequeña posible por probar, las pruebas deben estar enfocadas en cada método de la clase y posibles estados de comportamiento.

El caso de prueba deberá contener la clase enfocada, el propósito de la prueba, los estados del objeto que serán analizados, los métodos, una lista de excepciones posibles que debería arrojar el objeto en caso de errores y condiciones externas que puedan afectar su comportamiento en caso de existir.

Diseño de casos de prueba de integración.

El diseño basado en pruebas de integración no tienen en sí un control jerárquico o de estructuras, tal como es común en otro tipo de pruebas, por lo que, en el paradigma de objetos, las pruebas de integración pueden ser:

Pruebas basadas en hilos

Basadas en la integración de ciertas clases necesarias para responder a un evento o tarea asignada al sistema.

Pruebas basadas en uso

Primero se prueban de manera unitaria las clases que funcionan de manera unitaria, es decir, las clases independientes. Despúes, se pondrán a prueba las clases dependientes, aquellas que necesitan una de otra para funcionar correctamente. O bien, que requieren la intervención de las clases independientes.

En sí, existen algunas diferencias entre las pruebas convencionales de software en comparación con las pruebas en sistemas basados en objetos, por lo que vale la pena reconocer estas diferencias e implementarlas siempre que sea pertinente. Las pruebas de software están enfocadas en encontrar errores, así que más vale tener un buen equipo de testers encargados de esto, ya que una vez que los errores hayan sido corregidos, se tendrá un sistema mucho más robusto y estable.