DOCUMENTACIÓN DE LAS PRUEBAS DE INTEGRACIÓN
INTRODUCCIÓNProbar completamente cada módulo es inabordable y además no resulta ni rentable ni práctico. Se trata de alcanzar un compromiso para que con el menor esfuerzo posible se puedan detectar el máximo número de defectos y sobre todo aquellos que puedan detectar los errores más graves. Para garantizar unos resultados fiables, además del juego de casos de prueba, es esencial que todo el proceso de prueba se realice de la manera más automática posible. Esto exige crear un entorno de prueba que asegure unas condiciones predefinidas y estables para las sucesivas pasadas, que
necesariamente se deben efectuar después de corregir los errores detectados en cada pasada anterior. El entorno deberá proporcionar, al menos, un informe con los resultados de las pruebas y un registro de los errores detectados con su discrepancia respecto al valor esperado.
Las técnicas de prueba de unidades responden a dos estrategias fundamentales • Pruebas de “caja negra”.
• Pruebas de “caja transparente”.(1) DESARROLLO
1ª Fase: Pruebas de introducción de datos
En la primera fase de pruebas se comprueba, manualmente (actuando como un jugador) que el programa resuelve las situaciones de entradas de datos erróneas o fuera de rango correctamente. Exactamente se comprueba que en la solicitud del número de jugadores el programa responde correctamente si se introduce un número inferior a dos o superior a cuatro, asi como la introducción de cualquier carácter que no sea un número. En la petición del número de ficha se comprueba que el programa responde correctamente si se introduce un número diferente al número de las fichas seleccionable así como la entrada de cualquier carácter que no sea un número.
Durante esta primera fase se detectan problemas con la clase Scanner. Esta clase es la utilizada para leer el texto introducido en la consola y pasárselo al método correspondiente. Exactamente lanza una excepción de tipo NoSuchElementException, siguiendo lo expuesto en el siguiente foro http://stackoverflow.com/questions/9273368/nosuchelementexception-scanner-java
se decide crear dos clases Scanner diferentes para el número de jugadores en la clase Parchis y otra para elegir el número de ficha en la clase Jugador.(En una parte posterior del desarrollo se elimina la clase Scanner)
2ª Fase: Pruebas de “caja negra” sin verificación del resultado.
En esta segunda fase de pruebas se pretende comprobar la integración de las diferentes clases, buscando errores tanto dentro de la clase (de unidad) como en la intercomunicación entre estas, que provoquen una finalización errónea del programa.
Después de esta fase de pruebas el programa deberá finalizar siempre mostrando una finalización, en cuanto al posicionamiento de sus fichas, coherente.
Para realizar esta prueba se modifican los métodos que recogen datos del jugador mediante la consola, para que estos parámetros sean creados automática y aleatoriamente. De esta manera se
agilizan las comprobaciones pues de otra manera habría que jugar las partidas de manera manual con el consiguiente incremento del tiempo dedicado a esta tarea.
Durante esta segunda fase se detectan varios errores de programación, por ejemplo, en el método
esMovible de la clase Jugador hay varias situaciones en las que la ficha “es movible” y no se detecta.
3ª Fase: Pruebas de “caja negra” con “caja transparente”
En esta tercera fase comprobamos que el programa funciona correctamente en las situaciones más “críticas” o “complejas” del programa. Para ello simulamos una partida previamente jugada en un juego de parchís real y esperamos que la posición de las fichas en una determinada jugada en el programa sea igual a la real.
La partida real es “guiada” para provocar las situaciones más inusuales, siguiendo el paradigma de prueba de “caja transparente”, tratando de que el programa transite por todos los posibles caminos de ejecución y ponga en juego todos los elementos del código. En la fase anterior de pruebas, en las que la tirada de los dados y la elección de ficha se realizaban de una manera aleatoria, pueden quedar inexplorados caminos que en un funcionamiento normal no serán muy frecuentados. Para poder simular la partida real se crean dos ArrayList con los diferentes valores del dado y las diferentes elecciones de fichas realizadas en la partida real. Además se introduce un modo PRUEBA para que el programa pueda funcionar en los dos modos con el mismo código. De esta manera se puede comprobar facilmente después de cada modificación que el programa sigue funcionando correctamente.
Para realizar las comprobaciones se utiliza la metodología Junit. El test se realiza sobre el método que incluye el bucle principal de la clase Parchis.
Los tests se realizan de manera escalonada en función del número de jugadas, Junit está diseñado para que cada método sólo sea reportado una vez por cada ejecución. Si se testeara cada vez que se sale del método en lugar de al finalizar la ejecución de todo el programa, la codificación sería más sencilla, de esta manera tenemos que parar el programa si queremos analizar una jugada anterior a la final.
Un ejemplo para verlo más claro:
En la segunda ronda paramos el juego en la jugada nº 8 (Parchis.jugadaLimitePrueba = 8)
se provoca que el jugador rojo saque un seis, para comprobar que después vuelve a tirar, en la segunda tirada sacaría un tres
si el programa ha funcionado correctamente al finalizar la segunda ronda la ficha roja con el identificador “9” deberá estar situada en la casilla “51”
lo comprobamos con JUnit
Detección de un error:
En la jugada (o tirada de dado) 27 la ficha 1 de color AMARILLO se mueve a la casilla SALIDA de color ÁZUL que está ocupada previamente por la ficha 8 de color ÁZUL. La casilla de SALIDA ÁZUL es la número 22.
Al realizar las comprobaciones de las fichas con Junit se detecta que la ficha AMARILLA no se encuentra en el lugar esperado (casilla SALIDA ÁZUL)
Detectamos dos errores:
1. Una ficha en su casilla salida es “comible”.
2. Cuando una ficha se come a otra, la primera no actualiza su atributo casillaActual que es el que determina su posición en el tablero.
Creamos un nuevo ticket en el TRAC para solucionarlo
una vez solucionado
se vuelve a pasar la misma prueba y se comprueba que ahora el resultado es el esperado
una vez, se comprueba cada requisito especificado en el documento de requisitos del proyecto. Por último esta prueba de Junit nos permite retirar de manera más segura métodos u otros elementos del código que a priori no se utilizan, basta con comentar la parte de código que sospechamos no se utiliza, y volver a pasar la prueba. Si la prueba se ejecuta correctamente tenemos casi la total seguridad de que ese método no se utiliza en la ejecución del juego.
(1) Resumen del capítulo 5 “Codificación y pruebas” del libro “Introducción a la Ingeniería del Software” de Jose A. Cerrada Somolinos.
