Instrucciones de la herramienta: Implementación de una prueba de componentes automatizada utilizando Rational QualityArchitect
En esta guía de la herramienta se proporciona una visión general de las tareas de prueba de unidad que se realizan con Rational QualityArchitect.
Herramienta: Rational QualityArchitect
Relaciones
Descripción principal

Visión general

En esta guía de la herramienta se proporciona una visión general de las cuatro tareas de prueba de unidad principales que se llevan a cabo con Rational QualityArchitect:

  • Prueba de unidad
  • Prueba del caso de ejemplo
  • Generación de fragmentos
  • Registro de sesión EJB

Una propuesta arriesgada es la de un proceso de desarrollo que posterga la prueba hasta que se puedan ensamblar todos los componentes en un sistema completado. Los defectos que se localizan de forma tan tardía en el ciclo vital son más difíciles de arreglar y tienen más probabilidades de causar retardos importantes en la planificación, en especial, si se trata de problemas de la arquitectura que es posible que requieran un rediseño para su corrección.

Incluso si un equipo tiene un nivel de confianza justificado en la calidad de los componentes del sistema, la confianza global del sistema puede seguir siendo inaceptablemente baja. Por ejemplo, si se considera un sistema sencillo que consta de cinco componentes, en el que cada uno se califica (bien por la métrica de cobertura de la prueba, bien por métodos menos cuantitativos) con una fiabilidad del 95 por ciento. Puesto que la fiabilidad del sistema es acumulativa, la valoración global es de 95 % x 95 % x 95 % x 95 % x 95 %, o bien, se sitúa justo por encima del 77 por ciento. Mientras que la posibilidad de problemas en cualquier componente puede ser sólo de 1 sobre 20, el sistema global se aproxima a 1 sobre 4 y, en este caso, se trata de un sistema con relativamente pocos componentes.

Por el contrario, un proceso de desarrollo que incorpore la prueba de componentes a través de un proceso de desarrollo iterativo ofrece varias ventajas importantes:

  • Los problemas se pueden localizar y arreglar en un contexto aislado, por lo que no sólo son más fáciles de reparar, sino que también son más fáciles de detectar y diagnosticar.
  • Puesto que la prueba y el desarrollo están estrechamente acoplados durante el ciclo vital, las medidas de progreso son creíbles, es decir, ahora el progreso se puede ver en términos de la parte del proyecto que está codificada y en funcionamiento, no sólo codificada.
  • Se minimizan las interrupciones de la planificación debidas a problemas imprevistos, por lo que la planificación global resulta más realista y se reduce el riesgo del proyecto.

Aunque realizar la prueba pronto ofrece importantes ventajas, la práctica está lejos de lo habitual, en especial, cuando se trata de probar componentes de la capa intermedia, sin la GUI.

¿Por qué? Porque requiere tiempo y resulta aburrido y, con frecuencia, en el pasado, los costes de superar estas cuestiones prácticas ha pesado más que las ventajas. Además, puesto que la mayoría de pruebas están adaptadas a un componente concreto, existen pocas posibilidades de reutilización. Muchas organizaciones reconocen el gasto inútil que supone compilar fragmentos y aprovechamientos de pruebas partiendo de cero, utilizarlos y, a continuación, desecharlos proyecto tras proyecto. Prefieren centrar sus recursos limitados en otras áreas.

Con QualityArchitect, realizar las pruebas pronto es, realmente, factible, puesto que los fragmentos y los aprovechamientos de pruebas se generan de modo automático, no sólo una vez, sino de modo incremental a medida que evoluciona el modelo durante todo el desarrollo. El proceso de desarrollo completo es, así, más estructurado, medido y visible, puesto que los resultados de las pruebas de los componentes facilitan criterios de entrada más enérgicos para evitar la prueba del sistema prematura. Gracias a QualityArchitect, los desarrolladores se pueden centrar en los aspectos creativos de la definición de pruebas, por lo que pueden dedicar tiempo a pensar sobre el mejor modo de ejecutar un componente, en lugar de escribir y depurar fragmentos y controladores de pruebas. Los desarrolladores y los arquitectos trabajan conjuntamente con los modelos visuales compartidos, lo que les permite desarrollar de forma natural una relación más productiva entre sí.

Esta guía de la herramienta se aplica al ejecutar Windows 98/2000/NT 4.0.

Pasos de la herramienta

En esta guía de la herramienta se tratan las tareas principales asociadas a la implementación de una prueba de componentes automatizada utilizando QualityArchitect:

  1. Pasos de requisitos previos para la prueba de unidad
  2. Implementar una prueba de unidad
  3. Implementar una prueba de caso de ejemplo
  4. Crear un componente de fragmento
  5. Utilizar el grabador de sesión de EJB

1.  Pasos de requisitos previos para la prueba de unidad

Para generar cualquier prueba utilizando QualityArchitect, si son para componentes COM de EJB, se debe crear y configurar un proyecto de Rational utilizando Rational Administrator. Dicho proyecto debe contener un almacén de datos de prueba para mantener todos los activos de prueba como, por ejemplo, agrupaciones de datos y resultados de la prueba, que se describe en la Guía de la herramienta: Configuración de proyectos utilizando Rational Administrator.

2.  Implementar una prueba de unidad

El objetivo de una prueba de unidad es validar que una operación concreta o un componente determinado proporciona el valor de retorno correcto para un conjunto de entradas dado. Las pruebas de unidad se crean fuera de la especificación de la clase en la vista lógica. El proceso de creación y ejecución de una prueba de unidad consta de tres pasos:

  • Generación de código de prueba de unidad
  • Generación de datos de prueba de unidad
  • Ejecución de la prueba y examen de los resultados

Generación de código de prueba de unidad

El código de prueba de unidad contiene todas las instrucciones necesarias para crear instancias del componente, llamar a la operación que somete a prueba y examinar el resultado devuelto con respecto a una línea base.

Para componentes COM
  1. En la vista lógica, seleccione la operación que someter a prueba en la interfaz de componentes.
  2. Pulse el botón derecho del ratón sobre la operación listada en la interfaz del componente y seleccione Rational Test > Generar prueba de unidad. Si se le solicita, es posible que durante este proceso deba registrar un proyecto de Rational.

QualityArchitect genera código compatible con Visual Basic 6 como salida del proceso.

En Visual Basic, primero debe intentar compilar el código. Todos los posibles errores de compilación se deben examinar. Bajo circunstancias determinadas, QualityArchitect no puede generar código para probar operaciones en las que se utilizan con frecuencia tipos de datos complejos. En estos casos, QualityArchitect inserta código no válido y, en el tiempo de compilación, resalta los segmentos de código en los que se requiere codificación manual. Una vez que se haya compilado el código, puede continuar con el paso siguiente, Generación de datos de prueba de unidad.

Para componentes EJB
  1. En la vista lógica, seleccione la operación que someter a prueba de la interfaz remota.
  2. Pulse el botón derecho del ratón sobre la operación y seleccione Rational Test > Seleccionar plantilla de prueba de unidad.
  3. Navegue a la plantilla adecuada para el servidor EJB. Para WebSphere, seleccione websphere_remote.template en la carpeta de métodos de EJBWebSphereBusiness. Para Web Logic, seleccione weblogic_remote.template en la carpeta de métodos de EJBWeb LogicBusiness.
  4. Seleccione Rational Test > Generar prueba de unidad. Si se le solicita durante el proceso, es posible que deba iniciar la sesión en un proyecto de Rational. 

QualityArchitect genera código Java como salida del proceso.

Puede utilizar el IDE o editor que prefiera para examinar el código Java. Rational Rose se entrega con el editor R2, que se puede utilizar para este objetivo.

Una vez que se encuentre en el editor, en primer lugar puede intentar compilar el código. Todos los posibles errores de compilación se deben examinar. Bajo circunstancias determinadas, QualityArchitect no puede generar código en el que se utilizan con frecuencia tipos de datos complejos. En estos casos, QualityArchitect inserta código no válido que no compila las líneas de código señaladas en las que se requiere codificación manual. Una vez que se haya compilado el código, puede continuar con el paso siguiente, Generación de datos de prueba de unidad.

Generación de datos de prueba de unidad

La medida verdadera de una prueba de unidad satisfactoria son los datos de la prueba. El código de prueba en sí es completamente desechable, puesto que QualityArchitect puede volver a generar código en cualquier momento. Mientras que QualityArchitect puede crear código de prueba, no puede crear datos de prueba significativos. Ésta es responsabilidad del analista o implementador. Se debe prestar atención al crear datos de prueba que validen pruebas positivas y negativas representativas. Los datos de prueba que se centran en las condiciones de límite de la lógica del componente son candidatos óptimos para los datos de prueba de unidad.

Para componentes COM
  1. En la vista lógica, seleccione la operación que someter a prueba en la interfaz del componente.
  2. Pulse el botón derecho del ratón sobre la operación y seleccione Rational Test > Crear agrupación de datos.
  3. Una vez que haya seleccionado Crear agrupación de datos, se muestra el diálogo Propiedades de la agrupación de datos. En este punto, puede seleccionar Editar datos de la agrupación de datos para empezar a entrar datos, o bien, seleccionar Definir campos de la agrupación de datos para que QualityArchitect genere datos de prueba automáticamente.
Para componentes EJB
  1. En la vista lógica, seleccione la operación que someter a prueba de la interfaz remota.
  2. Pulse el botón derecho del ratón sobre la operación listada en la interfaz remota y seleccione Rational Test > Crear agrupación de datos.
  3. Una vez que haya seleccionado Crear agrupación de datos, se muestra el diálogo Propiedades de la agrupación de datos. En este punto, puede seleccionar Editar datos de la agrupación de datos para empezar a entrar datos, o bien, seleccionar Definir campos de la agrupación de datos para que QualityArchitect genere datos de prueba automáticamente.
Cómo trabajar con agrupaciones de datos

Si selecciona Definir campos de la agrupación de datos, puede utilizar las posibilidades de generación de datos de prueba de QualityArchitect. QualityArchitect puede generar diversos tipos de datos genéricos, que se especifican en la lista desplegable del campo Tipo

Cuando haya seleccionado los tipos adecuados, seleccione el número de filas que generar y pulse Generar datos. Es bastante probable que QualityArchitect no pueda generar automáticamente todos los tipos de datos. Por ejemplo, QualityArchitect puede generar una lista genérica de ciudades de Estados Unidos, pero no dispone de la posibilidad de generar una lista válida de números de factura específicos del sistema para un sistema de pedidos. Estos datos se deben entrar de forma manual como un tipo de datos, o bien, directamente en una agrupación de datos. El valor de la creación de un tipo de datos con datos personalizados es que, desde este punto de vista, QualityArchitect puede generar el tipo de datos a partir de la interfaz Definir campos de la agrupación de datos. Si entra los datos directamente en la agrupación de datos, éstos sólo están disponibles para la agrupación de datos específica.

Cuando selecciona Editar datos de la agrupación de datos, entra directamente en datos de prueba significativos. Hay un campo para cada argumento, así como un campo para una devolución esperada y un campo para un error esperado. Cuando especifica un error, son entradas válidas tanto los mensajes de error de texto como de número de error. Si la operación requiere un objeto complejo como argumento, o bien, si debe devolver un objeto complejo, no puede insertar la referencia a objetos en la agrupación de datos. En vez de ello, divida el objeto para los tipos de argumentos simples que se requieren para compilar una instancia del objeto. Utilice los botones Insertar antes e Insertar después para añadir campos a la agrupación de datos para este objetivo. Debe modificar el código de prueba para compilar una instancia del objeto con los datos facilitados.

Ejecución de la prueba y examen de los resultados

´Después de crear tanto el código como los datos de prueba, puede ejecutar la prueba desde el IDE, o bien, planificar la prueba en un conjunto de aplicaciones de TestManager. Consulte la Guía de la herramienta: Ejecución de un conjunto de aplicaciones de prueba utilizando Rational TestManager para obtener más información sobre este tema.

  1. En cuanto se empieza a ejecutar la prueba, se le solicita que proporcione una ubicación para los resultados de registro de la prueba. Una vez que haya especificado una ubicación, TestManager coloca los resultados de la ejecución de la prueba en la ubicación indicada.
  2. Al finalizar la ejecución, TestManager muestra el registro de prueba. Para ver los resultados de la prueba, seleccione la pestaña Vista detallada de la ventana Visor de registros. Expanda la vista de árbol de los resultados para ver los detalles de la ejecución de la prueba. Puede acceder a más información pulsando el botón derecho del ratón sobre cualquier línea y seleccionando Propiedades.

3.   Implementar una prueba de caso de ejemplo

El objetivo de una prueba de caso de ejemplo es validar que una serie determinada de operaciones a través de una serie concreta de componentes se combina para realizar correctamente una tarea colectiva. Las pruebas de casos de ejemplo se crean a partir de diagramas de interacción, en especial, diagramas de secuencia y de colaboración. El proceso de creación y ejecución de una prueba de unidad consta de los tres pasos que se indican a continuación:

  • Generación de código de prueba de caso de ejemplo
  • Generación de datos de prueba de caso de ejemplo
  • Ejecución de la prueba y examen de los resultados

Generación de código de prueba de caso de ejemplo

El código de prueba de caso de ejemplo incluye todo el código de controlador de prueba necesario para crear instancias de los componentes, llamar a las operaciones que se someten a prueba y evaluar los resultados de las operaciones utilizando puntos de verificación. Los puntos de verificación son un mecanismo por el que el código de prueba puede ejecutar sentencias SQL con respecto a una base de datos para verificar la manipulación adecuada de los datos subyacentes.

Para componentes EJB
  1. Seleccione el diagrama de colaboración en el navegador.
  2. Pulse el botón derecho del ratón sobre el diagrama y seleccione Rational Test > Seleccionar plantilla ScenarioTest.
  3. Navegue a la plantilla adecuada para el servidor EJB. Para WebSphere, seleccione websphere_scenario.template en la carpeta EJBWebSphereScenario. Para Web Logic, seleccione weblogic_scenario.template en la carpeta EJBWeb LogicScenario.
  4. Abra el diagrama de colaboración o secuencia concreto que modela el caso de ejemplo que se somete a prueba. Es importante especificar los mensajes para los componentes en el diagrama que se va a probar. Los mensajes se pueden especificar efectuando una doble pulsación en la línea de mensaje y especificando un nombre en el recuadro de lista desplegable de la pestaña General. El nombre debe corresponder a la operación que se está probando. Además, las especificaciones de pueden modificar para incluir datos de guión de prueba.

    Por ejemplo, Rose expone, por omisión, la especificación de mensaje como:
    getTransactions(customerID : String)

    Esta especificación se puede modificar para incluir un único guión de datos, tal como se indica a continuación:
    getTransactions(customerID : String="BBryson")

    Para cada prueba de caso de ejemplo, QualityArchitect genera de modo automático una agrupación de datos para datos de guión de prueba. Se rellena la primera fila de datos del diagrama. A partir de este punto, puede añadir más filas.
  5. Para iniciar la prueba, pulse el botón derecho del ratón sobre el diagrama en el navegador y seleccione Rational Test > Generar prueba de caso de ejemplo. Si se le solicita que inicie la sesión en el proyecto, hágalo. 
  6. Se muestra un diálogo en el que se le solicita que seleccione los destinos de la prueba de caso de ejemplo. Seleccione todos los componentes del diagrama que van a formar parte de la prueba. Para cada componente seleccionado, se invoca la operación correspondiente especificada en el mensaje del componente.  
Para componentes COM
  1. Abra el diagrama de colaboración o secuencia concreto que modela el caso de ejemplo que se somete a prueba. Es importante especificar los mensajes para los componentes en el diagrama que se va a probar. Los mensajes se pueden especificar efectuando una doble pulsación en la línea de mensaje y especificando un nombre en el recuadro de lista desplegable de la pestaña General. El nombre debe corresponder a la operación que se está probando. Además, las especificaciones de pueden modificar para incluir datos de guión de prueba.

    Por ejemplo, Rose expone, por omisión, la especificación de mensaje como:
    getTransactions(customerID : String)

    Esta especificación se puede modificar para incluir un único guión de datos, tal como se indica a continuación:
    getTransactions(customerID : String="BBryson")

    Para cada prueba de caso de ejemplo, QualityArchitect genera de modo automático una agrupación de datos para datos de guión de prueba. Se rellena la primera fila de datos del diagrama. A partir de este punto, puede añadir más filas.
  2. Para iniciar la prueba, pulse el botón derecho del ratón sobre el diagrama en el navegador y seleccione Rational Test > Generar prueba de caso de ejemplo. Si se le solicita que inicie la sesión en el proyecto, hágalo. 
  3. Se muestra un diálogo en el que se le solicita que seleccione los destinos de la prueba de caso de ejemplo. Seleccione todos los componentes del diagrama que van a formar parte de la prueba. Para cada componente seleccionado, se invoca la operación correspondiente especificada en el mensaje del componente.  
Puntos de verificación

Para cada operación que se va a invocar, y al final de la prueba, se le solicita que inserte un punto de verificación. QualityArchitect utiliza punto de verificación para validar si las operación se han realizado correctamente. Aunque la arquitectura de puntos de verificación es abierta y ampliable, en la actualidad sólo se ha implementado el punto de verificación de base de datos. El punto de verificación de base de datos le permite entrar SQL para ejecutar la consulta. La consulta creada se ejecuta en el tiempo de prueba para validar si el componente manipula la base de datos correctamente.  

icono de Ayuda Puede implementar sus propios puntos de verificación. Para ello, siga los pasos que se indican en la ayuda en línea de QualityArchitect.

  1. Seleccione para insertar un punto de verificación.
  2. Seleccione el tipo de punto de verificación adecuado que insertar. A menos que haya implementado sus propios puntos de verificación, debe seleccionar PV de base de datos.
  3. Se presenta un compilador de consultas, que puede utilizar para establecer los parámetros de conexión a la base de datos y para compilar la consulta que se va a ejecutar para validar el funcionamiento correcto de la operación que se invoca. Para establecer esta conexión y crear la consulta, se requieren conocimientos básicos sobre la base de datos subyacente y la sintaxis SQL.

En esta fase se produce la salida del código necesario para crear instancias de todos los componentes, llamar a todas las operaciones y ejecutar los puntos de verificación insertados.

Generación de datos de prueba de caso de ejemplo

Para cada prueba de caso de ejemplo generada, QualityArchitect crea de modo automático una agrupación de datos para que contenga los datos de prueba. Si se han especificado datos en el diagrama, la primera fila de la agrupación de datos ya se ha rellenado con dicha información, así como la información relacionada con todos los puntos de verificación insertados. Si no es así, la agrupación de datos sólo contiene información relacionada con los puntos de verificación.

Para ver y editar la información, siga los pasos que se indican a continuación:

  1. En Rose, seleccione Herramientas > Rational Test > Barra de herramientas.
  2. En la barra de herramientas, seleccione el segundo elemento de la barra de herramientas para editar la agrupación de datos. QualityArchitect ha creado una agrupación de datos que contiene el nombre del diagrama de caso de ejemplo, que finaliza con _D. El algoritmo que se utiliza para denominar la agrupación de datos bastante compleja, por lo que resulta muy difícil predecir el nombre cada agrupación de datos en esta documentación.

Para editar los datos, siga los pasos básicos que se esquematizan en el apartado Cómo trabajar con agrupaciones de datos.

Ejecución de la prueba y examen de los resultados

Después de crear tanto el código como los datos de prueba, puede ejecutar la prueba desde el IDE, o bien, planificar la prueba en un conjunto de aplicaciones de TestManager. Consulte la Guía de la herramienta: Ejecución de un conjunto de aplicaciones de prueba utilizando Rational TestManager para obtener más información sobre este tema.

  1. En cuanto se empieza a ejecutar la prueba, se le solicita que proporcione una ubicación para los resultados de registro de la prueba. Una vez que haya especificado una ubicación, TestManager coloca los resultados de la ejecución de la prueba en la ubicación indicada.
  2. Al finalizar la ejecución, TestManager muestra el registro de prueba. Para ver los resultados de la prueba, seleccione la pestaña Vista detallada de la ventana Visor de registros. Expanda la vista de árbol de los resultados para ver los detalles de la ejecución de la prueba. Puede acceder a más información pulsando el botón derecho del ratón sobre cualquier línea y seleccionando Propiedades.

Para los puntos de verificación, no se proporciona ninguna indicación de Correcto o Incorrecto en la primera ejecución, que se utiliza para capturar una instantánea de los resultados de la consulta que se van a utilizar como datos de línea base para futuras ejecuciones de prueba.

Efectúe una doble pulsación en los puntos de verificación para visualizar un comparador que presenta los resultados de la consulta. Los resultados se pueden editar, por lo que, si la consulta no devuelve los resultados correctos, puede modificar los datos. Todas las ejecuciones subsiguientes de la prueba comparan los resultados de la consulta con los que se han capturado en la primera ejecución.

4.  Crear un componente de fragmento

Con frecuencia, los componentes que se prueban en una prueba de unidad o caso de ejemplo dependen de otros componentes para completar sus tareas. Los problemas surgen cuando los componentes secundarios no están operativos. En ocasiones, aún están en desarrollo, y otras veces tienen bugs. A pesar de ello, la prueba del componente primario no se debe detener hasta que los componentes secundarios están disponibles. En su lugar, con el objetivo de la prueba se pueden reemplazar los componentes no operativos por un fragmento o componente temporal. El fragmento no implementa la funcionalidad del componente real, simplemente, reacciona a las entradas. Los fragmentos devuelven una respuesta programada para un conjunto de valores determinado, sin implementar ninguna lógica. Se trata de una relación simple de respuesta de estímulo.

QualityArchitect puede crear fragmentos, fácilmente, tanto para componentes COM como para componentes EJB. Los fragmentos dependen de tablas de búsqueda para crear réplicas de la lógica empresarial de los componentes a los que están reemplazando. La tabla, implementada como una agrupación de datos, determina lo que debe ser el valor devuelto para un conjunto concreto de entradas.

El proceso de creación y despliegue de un fragmento consta de los tres pasos que se indican a continuación:

  • Generación de un componente de fragmento
  • Generación de una tabla de búsqueda de fragmento
  • Despliegue del fragmento

Generación de un componente de fragmento

Cuando genera un fragmento, debe generar un componente completo. Para las operaciones que va a fragmentar, necesita crear una tabla de búsqueda. Un componente fragmentado, que contiene código de fragmento para todas las operaciones de dicho componente, es la salida del proceso de generación de fragmento. No puede fragmentar una sola operación.

Para componentes COM
  1. En la vista lógica, seleccione la interfaz del componente.
  2. Pulse el botón derecho del ratón sobre la interfaz y seleccione Rational Test > Generar fragmento. Se le solicita la ubicación en la que desea colocar el código de fragmento generado. Seleccione la ubicación. El código se genera.
Para componentes EJB
  1. En la vista lógica, seleccione la clase de implementación de bean. 
  2. Pulse el botón derecho del ratón sobre la clase y seleccione Rational Test > Generar fragmento. Se le solicita la ubicación en la que desea colocar el código de fragmento generado. Seleccione la ubicación. El código se genera.

Generación de una tabla de búsqueda de fragmento

Para crear réplicas de la lógica del componente real, el fragmento debe conocer la reacción del componente real cuando se proporciona un conjunto de argumentos. La lógica se mantiene es una tabla de búsqueda, que especifica el valor o error que se debe devolver para un conjunto concreto de argumentos. Debe crear una tabla de búsqueda para cada operación del componente que se fragmenta.

Para componentes COM
  1. En la vista lógica, seleccione la operación de la interfaz del componente.
  2. Pulse el botón derecho del ratón sobre la interfaz y seleccione Rational Test > Crear tabla de búsqueda. Se muestra el diálogo Propiedades de la agrupación de datos.
  3. Para crear la tabla de búsqueda, siga los mismos pasos básicos que se esquematizan en el apartado Cómo trabajar con agrupaciones de datos. Esta tabla se utiliza para especificar los valores o las excepciones que devolver para un conjunto determinado de argumentos.
Para componentes EJB
  1. En la vista lógica, seleccione la operación de la clase de implementación de bean. 
  2. Pulse el botón derecho del ratón sobre la clase y seleccione 
  3. Rational Test > Crear tabla de búsqueda. Se muestra el diálogo Propiedades de la agrupación de datos.
  4. Para crear la tabla de búsqueda, siga los mismos pasos básicos que se esquematizan en el apartado Cómo trabajar con agrupaciones de datos. Esta tabla se utiliza para especificar los valores o las excepciones que devolver para un conjunto determinado de argumentos.

Despliegue del fragmento

Una vez que se hayan generado el fragmento y la tabla de búsqueda, el fragmento se puede desplegar en lugar del componente existente. Este proceso es específico del entorno, y en la ayuda en línea de QualityArchitect se proporciona una guía para la realización de esta tarea.

5.  Utilizar el grabador de sesión de EJB

El grabador de sesión de EJB es una aplicación Java que le permite interactuar con componentes EJB desplegados. Esta funcionalidad sólo está disponible para Enterprise JavaBeans, no para componentes COM.

El proceso de utilización del grabador de sesión de EJB implica los pasos siguientes:

  • Inicio de una sesión de grabación de XML
  • Conexión al servidor EJB
  • Creación de una instancia del bean que se somete a prueba
  • Invocación de la operación en el bean
  • Inserción de puntos de verificación y código Java
  • Generación de código de prueba de la grabación de la sesión de EJB

El grabador de sesión de EJB se puede utilizar de dos modos: grabando y sin grabar. Cuando se graba, todas las acciones llevadas a cabo se graban en un registro XML que el grabador de sesión de EJB convierte en código Java ejecutable. El código contiene todas las llamadas a método, el código Java insertado y los puntos de verificación. Cuando se utiliza la modalidad sin grabación, la herramienta se limita a crear instancias de los EJB y a invocar sus operaciones.

  1. Para conectar al servidor EJB, debe proporcionar el URL de Proveedor e InitialContextFactory para conectar al servidor EJB. Esta información debe ser la misma que la que utiliza el código de cliente para conectar al servidor. Puede obtener la información de conexión por omisión para WebSphere y Web Logic en la documentación del producto en línea. 
  2. Cuando haya proporcionado la información de conexión, seleccione Conectar. Se presenta una lista de los beans desplegados en el servidor. Puede interactuar con uno o más beans durante una sesión y, en este punto, debe seleccionar el primer bean con el que interactuar.
  3. Debe crear una instancia del primer bean que se somete a prueba. Seleccione el método de creación adecuado de la mitad superior de la ventana Métodos. Si el método de creación requiere parámetros específicos, especifíquelos en la sección Parámetros. Cuando haya terminado, seleccione Invocar para crear una instancia del bean.
  4. Después de crear la instancia del bean, el grabador de sesión de EJB le presenta las distintas operaciones disponibles en el bean. En la mitad superior de la ventana Métodos se muestran las operaciones propias del bean, y en la mitad inferior se muestran las operaciones heredadas. Por norma general, las operaciones heredadas no se prueban. Una vez que haya seleccionado la operación que desea probar, puede proporcionar los parámetros adecuados para ésta en la ventana Parámetros.
  5. Si el parámetro es un objeto complejo, se muestra una parte inferior denominada Nuevo, que abre otra ventana en la que se presenta un diálogo que le permite crear una instancia del objeto necesario. La ventana muestra todos los constructores y los argumentos necesarios para compilar una instancia del objeto. Después de facilitar la información del constructor, debe denominar el objeto a fin de que más tarde se pueda hacer referencia al mismo durante la grabación, si fuera necesario.  
  6. La asignación de nombres para parámetros tiene un valor, puesto que estos valores se vuelven a utilizar durante la grabación de la sesión. Si proporciona un nombre, QualityArchitect puede rellenar el valor de cualquier campo de parámetro cuando se pulsa el botón derecho del ratón sobre dicho campo.
  7. Al pulsar Invocar, se llama a la operación con los parámetros proporcionados. El valor de retorno se muestra en el campo Último valor de retorno. Si se necesita este valor como entrada de una llamada posterior, se puede arrastrar y soltar en el campo necesario. También puede pulsar el botón derecho del ratón sobre el mismo cuando el ratón señala al campo del parámetro en el que se va a insertar el valor. Para determinar los valores que presentar en el menú de pulsación del botón derecho del ratón, el grabador de sesión de EJB compara el tipo de parámetro con los tipos anteriores que se han utilizado durante la prueba.  
  8. En cualquier momento de la sesión, puede insertar código Java y puntos de verificación del menú Insertar. Los puntos de verificación son los mismos que los que se utilizan al generar código de prueba de caso de ejemplo. De igual modo, se puede insertar código Java para realizar proceso adicional.
  9. Si se encuentra en modalidad de registro, puede convertir la grabación basada en XML en código Java una vez que haya completado todos los pasos de la prueba. Pulse Detener para llevar a cabo esta acción. Se le solicita que convierta el código XML en código Java, y necesita indicar un nombre de sesión y un nombre de script. El código Java, que se puede ejecutar para crear réplicas de los pasos llevados a cabo durante la grabación, es la salida del proceso.