Sikuli - Automatización de pruebas del GUI

¡Y no sólo del GUI(interfaz gráfica de usuario)! Cada vez soporto menos repetir mñas de un par de veces una tarea. Enseguida, busco una forma de automatizarla. Y estoy encantado con Selenium IDE. Ahora mi nivel de vaguedad ha llegado a tal punto, que tampoco quiero arrancar las aplicaciones del escritorio y cargar las pruebas. Siempre o casi siempre lo mismo, quiero pulsar un botón y que se arranque el navegador, se compiler y se despliegue el proyecto, arrancar selenium IDE, cargar las pruebas, que se ejecuten, que se comprueben los resultados,...

Mi último descubrimiento en este campo, con el que espero conseguirlo, es SIKULI.

Permite automatizar la interacción con todo lo accesible y visible en el escritorio, para un montón de plataformas, Windows, Mac, Linux,...

En ello estoy. Prometo compartir mis éxitos y fracasos en ésta tarea :)

Ruta relativa de los ficheros desde JMETER

MERDE! Después de traducirlo y probarlo, resulta que la solución que pongo a continuación sólo funciona para ficheros de entrada y salida de los listeners, pero no para scripts externos en samplers. ¡SHIT! ¿Alguien sabe cómo se podría hacer también para samplers?

En los distintos sitios donde podamos hacer referencia a ficheros externos al plan de pruebas, las rutas de los mismos se pueden especificar de dos maneras distintas:

• ruta absoluta
• ruta relativa

Las rutas relativas se resuelven en base al directorio actual de trabajo (que por defecto es bin/, donde se encuentra el jmeter.sh o jmeter.bat). A partir de la versión 2.4 de JMeter (aleluya!), existe la posibilidad de utilizar rutas relativas al directorio que contiene el fichero correspondiente al plan actual de pruebas (el fichero JMX). Para ello, la ruta debe comenzar con "~/" (o lo que hayas definido en la propiedad jmeter.save.saveservice.base_prefix, que normalmente se encuentra comentada en el fichero bin/jmeter.properties). En ese caso, las rutas se asumirán como relativas a la localización del fichero JMX.

#jmeter.save.saveservice.base_prefix=~/

Si cambiamos la propiedad y tenemos pensado ejecutar el plan de pruebas en otras instalaciones de jmeter, tendremos que redefinir en ellas también dicha propiedad. Por lo que, por lo general, lo mejor es dejarla como está, para evitarnos quebraderos de cabeza en la portabilidad.

El texto original, que he traducido, se puede encontrar en la sección de listeners del manual de JMeter.

Tiene toda la lógica, y no se entiende que no se haya incluido desde el principio. Desde que apareció la posibilidad de añadir elementos externos al plan de pruebas, debía existir de referenciar esos elementos con relación al fichero de definición del plan y no al ejecutable de jmeter. Así puedo empaquetar y compartir los elementos propios de un plan de pruebas, sin necesidad de restringir la instalación de JMeter en los demás equipos donde quiera que se ejecute.