Pruebas de sistema: Concordion

He aquí cómo realizar las pruebas de todo el sistema. En mi caso, suelo utilizar Concordion , que es una aplicación que descubrí no hace mucho y que me está facilitando la vida.

Antes de nada, advertir que esta es la manera en la que YO uso concordion. Soy bastante novato con la herramienta y es posible que haya miles de modos mejores.

El problema

En la empresa en la que trabajo debemos proporcionar una batería de pruebas para que otro departamento se asegure de que el software que proporcionamos funciona como debe. Se supone que, además de las pruebas que les indicamos, ellos realizarán más pruebas adicionales.

Estas pruebas de caja negra deben estar automatizadas en la medida de lo posible, ya que se pasarán muchas veces.

Pero… ¿Cómo le indicas a gente que no tiene ni idea de programar -en su mayor parte- cómo debe probar un programa? ¿Y si en lugar de un programa es una librería? ¿Y si, además, tiene accesos al directorio activo de Windows y guarda datos en una base de datos?

Hasta antes de conocer Concordion el sistema era (no me peguéis) una hoja excel con un “script” a lanzar, chequeable. Lamentable, ¿verdad?

Concordion: primeros pasitos

Concordion me ha permitido automatizar bastante esa misma hoja Excel. De hecho, ahora el formato es completamente diferente.

Por una parte, creo una página HTML que sólo contiene el índice de las cosas que quiero probar. En esta página, los primeros puntos son siempre los mismos:

• Un link a una página con instrucciones, que será estática, sin tests, aunque la añado como página Concordion para que éste la trate igual que al resto.
• Un link a una página especial que muestra cierta configuración. Esto lo explicaré después.
• Un link a las primeras pruebas, que comprobarán el manifest.mf.

Estos enlaces se realizan con concordion:run para que se lancen automáticamente cada vez.

A partir de ahí comienzan las pruebas serias.

Configuración

Hay muchos valores que no puedo darles a otros departamentos: Direcciones IP, login/password de mi usuario en el directorio activo, acceso a BBDD, etc. Además, si lo encripto y lo añado al código, me encuentro con el problema de que es posible “que no se lo crean”, o que otro baje el código del repositorio y sepa mis contraseñas.

Por esa razón decidí leer un archivo de propiedades (properties) en el que guardo estas propiedades. A mí no me gusta que se sepa mi contraseña, pero no me importa saber la de los demás :D así que lo primero que hago es cargar este archivo y pintarlo en una página web que espero que después me devuelvan para así saber porqué no les está funcionando.

Comprobaciones iniciales

Es muy sencillo utilizar introspección para preguntarle a un JAR por su manifest. De esta manera obtengo el número de versión (que compararé con uno de los valores de la configuración) y otra serie de parámetros hardcoded, como el nombre del componente.

Incidencias

Una vez he terminado la batería de pruebas, cuando aparece un problema nuevo lo único que hay que hacer es añadir el problema como una prueba más. Así se probará en todas las futuras versiones.

Si el problema es de configuración, lo mejor es buscar la prueba que está fallando y añadir un apartado del tipo “Comprobaciones en caso de error”. De esta manera quedará documentado, y sólo será necesario leerlo en caso de que vuelva a surgir el mismo problema.

Pruebas de estrés

Mezclar las pruebas habituales y las pruebas de estrés es un problema, ya que las primeras serán muy frecuentes y las segundas tardan mucho.

Por eso mismo me he inventado un pequeño sistema: Creo un programa principal admite opciones. En función de las opciones (simplificadas) decido qué clase principal voy a lanzar. Después utilizo JUnit para cargar la clase seleccionada. Si le añadimos un poco de ayuda en línea con las opciones disponibles y hacemos que todo sea fácil de modificar, tenemos un código muy limpio, reutilizable y útil.

Código

Como ya dije, es algo que hago en la empresa y, por lo tanto, es parte de ella. De todas maneras, si alguien está muy interesado, podemos tratar de construirlo aquí, paso a paso, entre todos.

El paso siguiente

Por supuesto que esto no es la panacea ni algo definitivo. Es una manera de explicar a otros compañeros como funciona un componente y demostrar que funciona correctamente. Si tienen acceso al código, podrán saber cómo realizar ciertas funcionalidades, y si no, podrán comprobar que todo funciona correctamente. La posibilidad de modificar parámetros hace que se crean que la batería funciona correctamente (ejemplo: si ponen un password erróneo a propósito, deberá fallar).

Aún está muy presente el componente humano, pero es un pasito en la calidad. El siguiente paso será instalar un servidor Hudson que descargue el código por la noche, lo compile, lo pruebe y, si es válido, genere un paquete de instalación y una nueva revisión. Si no es válido nos avisará inmediatamente.

Es pronto para hacerme ilusiones con el servidor Hudson, pero todo se andará…

Enlaces

Si Concordion se aprende a manejar en media hora… ¿Para qué necesitamos más? :P