Herramientas libres para pruebas de sistema/aceptación en Java.

Saludos.

Una de las cosas que he estado haciendo aprovechando la tranquilidad de las navidades es ojear herramienta que me permitan hacer
pruebas del sistema/aceptación sobre aplicaciones Java. A continuación os cuento un resumen superficial de mis opiniones.

El problema:

Quiero escribir una prueba que verifique que una aplicación tipo bloc de notas carga correctamente un archivo del sistema. La
aplicación elegida fue, al principio, el Notepad que se incluye como ejemplo en el paquete J2SE. Como me dio problemas con
algunas herramientas, al final hice las pruebas con Stylepad, que también se incluye como ejemplo en J2SE.

Las herramientas:

Lo que buscaba es una herramienta que me permitiera indicar las mismas secuencias que haría una persona que cargara un archivo. Es decir: pulsar en el menú file > open, navegar hasta una carpeta predeterminada, seleccionar en un archivo concreto y pulsar el botón open. Para evitar tener que pelearme con lenguajes o archivos XML, busqué herramientas que me permitan grabar y reproducir todas esas acciones.

Las elegidas fueron 3: Abbot (link) , JFCUnit (link)y Marathon (link).

Abbot:

Abbot sirve tanto para probar componentes de manera aislada como para grabar y reproducir una secuencia de acciones. La herramienta viene con un editor (llamado Costello) muy completo que facilita la tarea de grabar secuencias, construir casos de prueba, y reproducirlas. No fue nada difícil echarla a andar.

Con el editor ejecuté la aplicación y capturé todas las pulsaciones de ratón perfectamente. El editor, además, registró todos los componentes (JMenuBar, JPane, JTextPane, etc. ) implicados en la secuencia. A la hora de añadir asertos, no tuve más que elegir el componente, elegir la propiedad que quería comprobar y el valor al que iba a comparara. Realmente sencillo.

Ahora vienen las cosas malas. Abbot almacena los casos de prueba en un XML bastante complejo, lo que hace difícil hacer pruebas sin grabar/reproducir. Además, el editor siempre se colgaba con bastante rapidez. La descripción de errores es muy poco clara, ya que se limita simplemente a mostrar el texto de la excepción, lo cual no tiene ninguna utilidad para mí que no conocía como estaba hecha la herramienta por dentro.

JFCUnit:

JFCUnit permite realizar pruebas unitarias de interfaces gráficas de usuario y pruebas del sistema. A diferencia de Abbot y Marathon, esta herramienta no trae ningún editor que permita capturar/reproducir. Para grabar y reproducir hay que escribir un par de programas en programa Java, fácil de hacer una vez que se investiga a fondo en la documentación y ejemplos. Además, es necesario modificar el código de la prueba a mano para añadir los asertos. Además, la prueba no fue capaz de grabar mi interacción con el FileDialog para seleccionar el archivo a abrir.

Las pruebas también se almacenan en XML. Aunque la documentación de JFCUnit es muy completa, falta una buena referencia de las etiquetas y sus atributos. algo indispensable ya que no dispone de un editor.

Marathon:

Esta herramienta sólo sirve para pruebas de sistema/aceptación, no permitirnedo escribir pruebas para componentes de manera individual. En esta herramienta las pruebas nos e guardan en XML sino en Python (y se procesan con JPython). Esto hace que el código sea muy compacto, muy legible y que tengamos toda la potencia de Python a nuestra disposición.

Aunque el editor no es tan completo como el editor de Abbot, incluye un menú contextual sobre la aplicación a prueba que permite añadir comprobaciones al mismo tiempo que se graba. Sin embargo también presenta problemas. El más importante es que, al igual que en la herramienta anterior, no se ha capturado la interacción con el diálogo para abrir un archivo. La documentación, aunque muy buena para empezar, se queda muy corta cuando quieres profundizar.

 

Conclusiones:

En una primera aproximación, no creo que ninguna de estas tres sea la herramienta definitiva. La herramienta que más me ha gustado es Marathon, sin duda por trabajar en Python. He encontrado mucho más cómodo entender código en Python que lenguajes propios de etiquetas. Marathon, además, es capaz de ocultar los detalles de la interfaz gráfica mejor que las demás. Esto es muy útil cuando queremos escribir las pruebas antes de tener la interfaz gráfica, o para evitar tener que volver a grabar todas las pruebas por algún cambio en la interfaz.

Estas navidades también estuve investigando algunas herramientas para probar aplicaciones web. En un futuro post, dentro de un mes más o menos, hablaré de ellas. Por supuesto escribiré más mensajes mientras.

 

Probando excepciones con JUnit.

Saludos.

Escribir una prueba con JUnit que compruebe si salta o no una excepción es muy sencillo. Por ejemplo, supongamos que queremos probar un método con la
siguiente cabecera:

public Empleado obtenerEmpleado(String DNI)
  throws DNIErroneo

Vamos a escribir, en primer lugar, una prueba que compruebe que cuando le indicamos un DNI correcto, no lanza la excepción:

public void testDNICorrectoNoExcepcion() {
 try {
  // Nota: es un DNI inventado. Supongamos que es correcto
  obtenerEmpleado("18665230F");
 } catch (DNIErroneo e) {
  fail();
 }
}

Como se puede ver, si surge una excepción se ejecuta fail(), lo cuál termina el caso de prueba con error. Si no, termina normalmente.

Ahora vamos a escribir una prueba que verifique lo contrario. Le indicaremos al método un DNI erróneo y verificaremos que nos devuelve una excepción.

public void testDNIErroneoExcepcion() {
 try {
  // Nota: es un DNI inventado. Supongamos que es correcto
  obtenerEmpleado("18665230F");
 } catch (DNIErroneo e) {
  return;
 }
 fail();
}

Ahora, fail() se ejecutará si no ha aparecido la la excepción de DNI erróneo. Si aparee cualquier otra excepción, la prueba también fallará.