Tests de Selenium con librerías de componentes JSF: Apache Tomahawk.

0
13961

Tests de Selenium con librerías de componentes JSF: Apache Tomahawk.

0. Índice de contenidos.

1. Introducción

En este tutorial vamos a hablar de cómo escribir tests funcionales con Selenium IDE sobre interfaces de usuario construidas con
librerías de componentes visuales JSF y, en concreto, con Apache Tomahawk y uno de sus componentes.

De la mano de nuestro compañero Victor hemos tenido la oportunidad de asistir a una charla sobre Selenium y en adictos podeis encontrar también tutoriales sobre toda la suite de productos de Selenium.

Apache Tomahawk es una librería de componentes visuales JSF, que extiende los componentes de la implementación de referencia o la de la propia implementación de Apache (Myfaces) y proporciona los componentes más usuales para la creación de interfaces web.

En la redacción de este tutorial se da por hecho que el lector tiene experiencia con JSF y está familiarizado con Selenium IDE.

2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Asus G1 (Core 2 Duo a 2.1 GHz, 2048 MB RAM, 120 GB HD).
  • Sistema operativo: Windows Vista Ultimate.
  • JDK 1.5.0_15
  • Eclipse 3.4, con q4e.
  • Apache Tomahawk 1.1.6.2
  • Firefox 3.0.7, con Selenium IDE.

3. Identifica tus componentes.

En la generación de árboles de componentes JSF se recomienda que cada nodo, cada componente, tenga asignado un identificador. Si el programador no asigna uno, la implementación se lo inventa, crea un id autogenerado.

Por definición, un identificador es único, no pueden existir dos componentes con el mismo id, de hecho se producirí­a una excepción el renderizado.

Cuando un componente JSF se renderiza, esto es, se traduce a html (o xhtml, dependiendo de la librerí­a) el id asignado al componente se suele pintar en el valor del atributo id de la etiqueta html correspondiente al mismo (depende de la implementación y del componente). Además si el componente se encuentra dentro de un formulario se antepone el nombre del mismo, más dos puntos.

Si estamos grabando las interacciones con la interfaz web desde Selenium IDE sobre un componente que tiene un id, lo normal es que el xpath asignado haga referencia al mismo.

Con todo lo expuesto, si identificamos correctamente nuestros componentes y grabamos normalmente estarí­a todo listo, pero como vamos a comprobar a continuación hay excepciones.

4. Escribir tests que perduren.

Ya no hablo de grabar, puesto que si queremos que nuestros tests perduren en el tiempo, de modo que se puedan hacer tests de regresión debemos comprobar que tras la grabación no se hace referencia a algo que en un futuro no pueda ser uní­voco. Esto es:

  • si el xpath del componente tiene un id autogenerado, cuando insertemos un nuevo componente en el árbol que le preceda en la jerarquí­a, dejarí­a de funcionar el test, y
  • tenemos que comprobar que la grabación ha sido capaz de identificar el nodo del árbol DOM por su id y no por la ruta de etiquetas html (table/tbody/tr/td[0]/…), puesto que si esta cambia, dejará de funcionar el test,

En definitiva, hay que revisar el test que se graba inicialmente de modo manual. Cuanto mejor hayamos identificado nuestros componentes, menos revisión manual será necesaria.

4. Cuando la grabación no captura los eventos.

Hay ocasiones en las que la grabación con Selenium IDE no captura los eventos, así las interacciones sobre el componente <t:jscookmenu /&gt de Apache Tomahawk.

En tal caso tenemos que revisar el código fuente del árbol DOM generado para comprobar qué evento no se está capturando (lo siguiente es una captura con firebug):

Selenium IDE no es capaz de grabar los eventos: onmousedown y onmouseup, tenemos que escribirlos nosotros, con el problema añadido de no tener identificadores propios en los items del menú, aunque se los asignemos a los componentes, en la renderización no se transladan al html, son autogenerados.

Como véis, el menú de Apache Tomahawk es el mejor ejemplo de componente JSF díficil de testear.

Lo único que podemos usar para identificar de forma unívoca cada item del menú es el texto del enlace. Para la opción «Guardar» del siguiente menú:

El código del test sería el que se muestra a continuación:

A


	mouseOver
	//div[@id="menutoolbar"]//td[@class="ThemeOfficeMainItem" ]/span[text()="Archivo"]
	


	waitForVisible
	//div[@id="menutoolbar"]//td[@class="ThemeOfficeMenuItemText" and text()="Guardar"]
	


	mouseDown
	//div[@id="menutoolbar"]//td[@class="ThemeOfficeMenuItemText" and text()="Guardar"]
	


	mouseUp
	//div[@id="menutoolbar"]//td[@class="ThemeOfficeMenuItemText" and text()="Guardar"]
	


:

  • Añadir al xpath el estilo del td no es del todo necesario, más si tenemos todo el menú dentro de un div claramente identificado, como es nuestro caso (<div id=»menutoolbar»…). Tened en cuenta que el estilo es personalizable y si se modifica el mismo el test dejaría de funcionar, con lo que se puede prescindir de la condición @class=»» .
  • Si el código html del test termina en un test de JUnit, debería refactorizarse para que fuese un método dentro de una clase de utilidades.
  • Si tuvieramos la aplicación internacionalizada, dentro del test de JUnit podríamos cargar los mensajes internacionalizados de un fichero de recursos.

Si tenemos dos items dentro del menú con el mismo texto, necesariamente tendremos que hacer referencia al ID autogenerado del submenú puesto que la forma en la que se pintan los items del menú no es jerárquica, la tabla de los submenus no se encuentra dentro de la tabla del menú al que pertenecen.


	mouseUp
	//div[@id='cmSubMenuID3']/*//td[@class='ThemeOfficeMenuItemText' and text() = 'Listado']
	


5. Conclusiones.

Este tipo de complicaciones podemos encontrarlas con otros componentes de ésta misma librería y con otras, hasta que los desarrolladores de las mismas realizen sus propios tests con Selenium IDE.

Hasta entonces, salvamos las vicisitudes.

Os recomiendo este tutorial de xpath y hacer uso extensivo de firebug y de la función $x(») en su consola, puesto que es como la función $(») de jquery o $$(») de prototype.

Un saludo.

Jose

mailto:jmsanchez@autentia.com

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad