Matchers en la localización de componentes

Hola a tod@s,

Hoy quiero hablar en esta entrada del término Matcher y de como estamos aplicando este concepto a nuestra herramienta.

SWTBot proporciona funcionalidad para localizar widgets de Eclipse y SWT. Los métodos para encontrar los widgets pueden extenderse también para la localización de otros tipos de componentes gráficos. Además, la localización se consigue gracias a unos Matchers que proporcionan normas para la búsqueda de componentes y que pueden ser ampliados para

avanzar en técnicas de búsqueda. Dichos Matchers permiten localizar los widgets de la interfaz para la cual estamos definiendo los Casos de Prueba, consultando las siguientes

propiedades:

- texto que muestra el widget;

- label que etiqueta el widget;

- id que identifica el widget;

- tooltip que muestra el texto descriptivo del widget;

- group el grupo en el que está encapsulado el widget;

- mediante la combinación de las anteriores propiedades.

Una vez seleccionado el widget que queremos tratar, SWTBot proporciona un entorno suficientemente potente para encapsular operaciones y consultas de estado de los widgets.

En la última versión subida a la forja sólo utilizamos en la búsqueda de componentes el texto, label, tooltip e identificador que reconoce al componente. Se ha optado por no complicar la localización de componentes por medio de una combinación de los matchers ya implementados. No obstante, en componentes limitados por sus tipos de matchers disponibles se debería desarrollar esta técnica para ofrecer un mejor uso a la herramienta. Tampoco se ha implementado la opción del matcher Group debido a la poca demanda en su utilización.

Una vez probado el buen funcionamiento de los matchers implementados, nos disponemos a ampliar esta funcionalidad de localización, con todas las posibilidades ofrecidas por la librería SWTBot. En la próxima versión subida, se reflejarán estos cambios.

Saludos.

Datapool como entrada, salida o E/S

Hola a tod@s,

En la herramienta implementada para la automatización de Casos de Prueba aparece un artefacto llamado Datapool (a partir de ahora DTP) que agiliza la alimentación y generación de Casos de Prueba. Primero definiremos el concepto de DTP.

El concepto de DTP incorpora la posibilidad de introducir datos de entrada y salida para cada Caso de Prueba a través de una estructura generalmente representada en forma de tabla de datos. De esta forma si deseamos realizar un Caso de Prueba que ingresa al sistema un número elevado de registros nuevos podemos crear un DTP que los contenga. Después creamos un Script de Prueba, que automatice dicho Caso de Prueba, cuyos comandos utilicen el DTP definido para ingresar los valores en la aplicación y recorrer cada dato diferente del DTP cada vez que se ejecute el Caso de Prueba.

En la presente definición hemos comentado que se pueden generar entradas y salidas para los Casos de prueba en el artefacto DTP, esta forma de construir los DTPs sería la idónea para aprovechar al máximo las ventajas del componente. No obstante en nuestra herramienta actual, debido a la forma de generar las instrucciones de entrad y salida, de momento sólo utilizaremos el DTP para alimentar las entradas de las instrucciones.

Dicho componente contiene atributos relacionados con información genérica del DTP como puede ser el nombre, ruta del artefacto y descripción del componente, así como las fechas de creación y modificación del DTP. El DTP como hemos indicado, estará compuesto por unas columnas y filas que registran los datos de entrada. Cada columna representará un valor de entrada y tendrá un

nombre y un tipo de dato representado por un formato determinado que será validado. Los

tipos de variables están predefinidos y para ello se ha creado un tipo de dato que determinará los posibles valores que podrá tomar una variable. Cada fila describe un conjunto de datos de entrada que han de ser tratado por el Caso de Prueba en concreto. Los datos registrados en

cada fila vienen expresados en celdas. Estas celdas estarán relacionadas con las columnas de la tabla, formando con este tipo de relaciones una matriz de datos dispuesta en filas y columnas.

Cada DTP es gestionado en contenedores de forma independiente y a su vez, un DTP podrá estar asociado a varios escenarios de pruebas para permitir su reutilización.

Con el refinamiento de la herramienta intentaremos sacar mayor provecho a este componente para que puedan convivir entradas y salidas en el mismo artefacto.