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:
-
Pasos de requisitos previos para la prueba de unidad
-
Implementar una prueba de unidad
-
Implementar una prueba de caso de ejemplo
-
Crear un componente de fragmento
-
Utilizar el grabador de sesión de EJB
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.
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
-
En la vista lógica, seleccione la operación que someter a prueba en la interfaz de componentes.
-
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
-
En la vista lógica, seleccione la operación que someter a prueba de la interfaz remota.
-
Pulse el botón derecho del ratón sobre la operación y seleccione Rational Test > Seleccionar plantilla de
prueba de unidad.
-
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.
-
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.
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
-
En la vista lógica, seleccione la operación que someter a prueba en la interfaz del componente.
-
Pulse el botón derecho del ratón sobre la operación y seleccione Rational Test > Crear agrupación de
datos.
-
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
-
En la vista lógica, seleccione la operación que someter a prueba de la interfaz remota.
-
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.
-
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.
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.
-
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.
-
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.
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
-
Seleccione el diagrama de colaboración en el navegador.
-
Pulse el botón derecho del ratón sobre el diagrama y seleccione Rational Test > Seleccionar plantilla
ScenarioTest.
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
Puede implementar sus
propios puntos de verificación. Para ello, siga los pasos que se indican en la ayuda en línea de QualityArchitect.
-
Seleccione Sí para insertar un punto de verificación.
-
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.
-
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:
-
En Rose, seleccione Herramientas > Rational Test > Barra de herramientas.
-
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.
-
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.
-
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.
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
-
En la vista lógica, seleccione la interfaz del componente.
-
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
-
En la vista lógica, seleccione la clase de implementación de bean.
-
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
-
En la vista lógica, seleccione la operación de la interfaz del componente.
-
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.
-
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
-
En la vista lógica, seleccione la operación de la clase de implementación de bean.
-
Pulse el botón derecho del ratón sobre la clase y seleccione
-
Rational Test > Crear tabla de búsqueda. Se muestra el diálogo Propiedades de la agrupación de datos.
-
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.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
|