Las características de prueba de componentes automatizada de los productos Rational Developer permite crear, editar, desplegar y ejecutar pruebas automatizadas para componentes Java, beans EJB y servicios web. Estas características están en conformidad con el estándar de perfilado de prueba UML y utilizan la infraestructura de prueba JUnit.
Con estas característica puede efectuar las acciones siguientes:
Todas las pruebas creadas con productos Rational Developer son ampliaciones de pruebas JUnit. Además, puede importar, editar y ejecutar pruebas JUnit existentes. Las características de prueba de componentes automatizada amplía JUnit con las siguientes familias de primitivas:
Una diferencia importante entre las acciones de validación y los métodos assert originales de JUnit es que, en las acciones de validación, las aserciones fallidas no detienen la ejecución de toda la suite de pruebas JUnit.
Para probar los componentes, primero debe crear un proyecto de prueba.
El proyecto de prueba está enlazado con uno o varios proyectos de desarrollo que contengan los componentes que desea probar. Los proyectos de desarrollo pueden incluir proyectos de desarrollo Java, proyectos de aplicación de empresa o proyectos web dinámicos. Los componentes de destino para cada prueba son conocidos como CUT (componente que se prueba).
Los proyectos de prueba contienen elementos orientados a ejecución (suites de pruebas y ejecuciones) y elementos orientados a código (scripts de comportamiento de prueba y apéndices). Puede examinar y editar suites de pruebas y ejecuciones de pruebas en la vista Navegador de pruebas, mientras que los scripts de comportamiento de prueba y los apéndices se muestran en la vista Explorador de paquetes.
Al efectuar pruebas, suele ser necesario quitar los componentes con los que interactúa el CUT. Esto permite probar el CUT aisladamente para así asegurarse de que se prueba el CUT y no otro componente. Como ocurre con las pruebas, un apéndice se define por comportamiento y por datos. El comportamiento de un apéndice se define en la clase del código de usuario del apéndice, que se puede ver y editar en la vista de código Java. Se proporcionan datos de apéndice en la tabla de datos de apéndice, que define el comportamiento de salida de una clase con apéndice en respuesta a algunas entradas. Con la tabla de datos de apéndice, se simula una clase con apéndice especificando la entrada real y los valores de devolución para cada método con apéndice.
Los apéndices se pueden generar automáticamente mediante el análisis del CUT durante la creación de la prueba.
El despliegue de pruebas es la fase en que se especifican las condiciones de la ejecución de la prueba. Principalmente para beans EJB, los datos de despliegue de prueba incluyen información del servidor de aplicaciones. Utilice el editor de suite de pruebas para elegir la configuración de servidor para desplegar el CUT. Las configuraciones de servidor se definen en la perspectiva Servidor.
Puede especificar una configuración de lanzamiento para cualquier componente de un proyecto de prueba (una suite de pruebas, un caso de prueba o una clase de equivalencia única) para que la prueba se pueda ejecutar con o sin opciones de perfilado o de depuración. Durante la ejecución de la prueba, un colector de datos supervisa el CUT para recuperar los resultados de la prueba.
La ejecución de prueba crea un resultado que puede verse en la vista Navegador de pruebas. Puede ampliar una ejecución de prueba para ver las pruebas individuales y sus veredictos (Válido, Anómalo, No concluyente o Error). Desde una prueba individual, puede ir a los detalles de los resultados visualizados en la vista Comparador de datos de prueba para ver los resultados reales de la prueba comparados con los resultados esperados.
Se proporciona una navegación cruzada contextual entre los veredictos de prueba, datos de prueba, suites de pruebas, scripts de comportamiento de prueba y las partes de código importantes del CUT.
La ventaja principal de la generación y configuración de un entorno de prueba persistente es que facilita la reutilización de las pruebas para la prueba de regresión. La prueba de regresión normal es un sistema fiable para asegurar que no se introducen defectos nuevos y que se arreglan los existentes.
Una buena práctica es crear las pruebas al principio del proyecto de desarrollo para así ayudar en la interpretación de las especificaciones del producto. A continuación, puede ejecutar las mismas pruebas periódicamente durante el proceso de desarrollo para detectar errores no esperados que puedan aparecer cada vez que el código se modifica o se desplaza a un entorno nuevo.