Pruebas unitarias
Una configuración incorrecta de las reglas en una aplicación puede causar demoras en el procesamiento de los casos. Cuando se produce un error, es posible que los usuarios finales tengan que reasignar el trabajo o que un administrador tenga que reparar un caso. Por ejemplo, consideremos un caso que se debe enrutar al Departamento de Cumplimiento. Si el caso se enruta en su lugar al Departamento Contable, un contador debe volver a enrutar el caso al Departamento de Cumplimiento. El contador pierde tiempo en volver a enrutar la asignación mientras el Departamento de Cumplimiento está inactivo. El resultado es una demora para el cliente durante la reasignación del caso.
Para evitar errores en la configuración, como asignaciones enrutadas incorrectamente, los desarrolladores prueban sus aplicaciones. La forma más básica para probar las aplicaciones son las reglas individuales del proceso de prueba unitaria. El proceso de prueba unitaria permite la entrega continua de aplicaciones mediante pruebas de calidad de las unidades más pequeñas de funcionalidad. En una aplicación de Pega, la unidad más pequeña es una regla individual.
El propósito del proceso de prueba unitaria es verificar que cada elemento de la aplicación, por ejemplo, una tabla de decisión o una definición de reportes, funcione como se espera. El proceso de prueba unitaria reduce el riesgo de que un error en la configuración de una regla se propague a otras reglas de la aplicación, lo que provoca demoras importantes en el procesamiento de los casos.
Use el proceso de prueba unitaria para reducir los errores en la configuración. Mediante el proceso de prueba unitaria de las reglas individuales, usted sabe que cada regla funciona como se espera cuando la configura. Por ejemplo, consideremos un árbol de decisión que evalúa una propiedad. Como se muestra en la siguiente imagen, la aplicación lee la propiedad de una página de datos que se obtiene de una definición de reportes. Si el árbol de decisión devuelve un resultado incorrecto, pero la página de datos contiene los datos correctos, puede aislar el error en el árbol de decisión.
Compruebe sus conocimientos con la siguiente actividad.
Reglas individuales del proceso de prueba unitaria
Usted puede probar una regla con los datos de prueba que proporcione haciendo clic en Actions > Run en la barra de herramientas del formulario de la regla en Dev Studio.
Nota: Para algunos tipos de reglas, como las reglas de archivos binarios, Pega no proporciona una opción para llevar a cabo el proceso de prueba unitaria. Si no se puede realizar una prueba unitaria de la regla, la opción Run no está disponible.
La apariencia de la ventana Run Rule varía según el tipo de regla, por lo que la forma de ejecutar una regla varía según el tipo de regla. En general, sin embargo, las reglas se ejecutan usando datos de una página de prueba que usted define para la prueba.
Cuando ejecuta la regla, el sistema utiliza la resolución de reglas. Si hace una prueba unitaria de una regla, y hay una versión superior de la regla, el sistema ejecuta la versión superior de la regla.
Registrar una prueba unitaria para las pruebas automatizadas
Después de ejecutar la prueba, también puede convertirla en un caso de prueba reutilizable que puede ejecutar en cualquier momento. Un caso de prueba identifica una o más condiciones que se pueden someter a pruebas y que se utilizan para determinar si una regla devuelve el resultado esperado. La creación de un caso de prueba reutilizable es compatible con el modelo de entrega continua, ya que proporciona un medio para probar las reglas con regularidad para identificar los efectos de las reglas nuevas o modificadas. Ejecute los casos de prueba siempre que se realicen cambios en el código que puedan afectar a la funcionalidad existente. Para obtener más información sobre el uso de casos de pruebas unitarias, consulte el artículo En qué consisten los casos de prueba unitaria de Pega Community.
Tip: Puede ejecutar automáticamente una prueba unitaria guardada desde la regla o la prueba unitaria mediante la función de pruebas de PegaUnit.
Para crear un caso de prueba, usted convierte una prueba en la ventana Run Rule (Ejecutar regla) y define los resultados que indican una prueba unitaria exitosa. Cada resultado esperado está compuesto por una aserción, que describe una o más condiciones que se deben someter a pruebas y el resultado esperado para cada condición. Los casos de prueba son compatibles con varios tipos de aserciones que prueban varios aspectos de la ejecución de la regla. Las aserciones disponibles para un caso de prueba varían según el tipo de regla probada.
Nota: Para obtener una explicación completa de los tipos de aserción compatibles y su uso, consulte el artículo Definición de los resultados previstos de la prueba con aserciones de Pega Community.
La siguiente tabla muestra algunos ejemplos de aserciones y sus usos.
| Tipo de aserción | Uso | Ejemplo |
|---|---|---|
| Propiedad | Prueba el valor de la propiedad especificada. Requiere la página en la que se define la propiedad, una operación de comparación y un valor de comparación. | pxUrgencyWork es igual a 10. |
| Resultados de la decisión | Prueba el valor devuelto por una regla de decisión. Requiere valores para cada propiedad de entrada necesaria para que la regla de decisión devuelva el resultado esperado. | Cuando Referred by employee (Referido por un empleado) es falso, devuelve RecruitingWB. |
| Tiempo de ejecución esperado | Prueba si una regla se ejecuta dentro de un tiempo permitido. Requiere una operación de comparación y un tiempo permitido en segundos. | El tiempo de ejecución esperado es inferior o igual a tres segundos. |
| Página | Prueba la presencia de una página en la memoria. Requiere el nombre de la página y una operación de comparación. | La página D_CoursesList no tiene errores. |
Cuando complete el conjunto de resultados esperados, guarde la configuración del caso de prueba. Puede acceder a un caso de prueba guardado desde la regla. La regla muestra todos los casos de prueba registrados para esa regla y el estado de cada caso de prueba desde su última ejecución. Si vuelve a ejecutar un caso de prueba y este falla, abra el resultado e identifique cada aserción que devolvió un resultado inesperado. Si un caso de prueba devuelve los resultados esperados, se muestra un estado verde de aprobado.
Puede agrupar casos de pruebas unitarias en una suite de prueba para ejecutar varios casos y suites de prueba en un orden específico. Cuando usted ejecuta suites de prueba de forma masiva, se ejecutan de manera secuencial, pero no en paralelo.
Preparación de casos de prueba
Para guardar un caso de prueba es necesario acceder a un ruleset que esté configurado para almacenar casos de prueba. No puede guardar casos de prueba en un ruleset que no esté configurado para almacenar casos de prueba.
Antes de registrar una prueba unitaria, trabaje con el administrador de sistemas para identificar un ruleset adecuado para almacenar los casos de prueba. Mantenga las pruebas portátiles e independientes, ya que las pruebas no deben depender de ningún otro caso de prueba ni interferir en ninguna prueba que se ejecute después. Cuando la aplicación de desarrollo se lance a producción, podrá migrar la aplicación sin incluir los casos de prueba.
Tip: Use la función Cleanup para restaurar las páginas del sistema del portapapeles o los cambios en los datos o las instancias de trabajo que se produzcan durante la ejecución de la prueba. La pestaña History mostrará un historial de los cambios.
Ejecución de un caso de prueba
En Dev Studio, la landing page Unit testing enumera todos los casos de prueba definidos para una aplicación y el estado de cada caso de prueba desde su última ejecución. En la landing page, también puede crear suites de prueba que estén compuestas por uno o más casos de prueba relacionados. Las suites de prueba unitaria de Pega ejecutan varios casos de prueba en el orden que usted especifique.
Tip: En el menú Configure , seleccione Application > Quality > Automated Testing > Unit Testing para tener acceso a la landing page.
Compruebe sus conocimientos con la siguiente actividad.
Prácticas recomendadas para configurar las pruebas unitarias
Las pruebas unitarias automatizadas ofrecen resultados ejecutables y el tiempo invertido en la ejecución y el mantenimiento de las pruebas automatizadas es menor que el tiempo invertido en las pruebas manuales. Asegúrese de que el desarrollo de las pruebas se produzca de forma simultánea al desarrollo de las reglas de su aplicación de Pega Platform™. Puede decidir reutilizar los casos de prueba durante el desarrollo en curso y otros equipos podrían aprovechar sus suites de prueba.
En qué momento crear pruebas unitarias automatizadas
Cuando una regla devuelva un resultado esperado, considere la posibilidad de configurar una prueba unitaria automatizada como sugiere la siguiente tabla de prioridades.
| Prioridad alta | Prioridad baja |
|---|---|
| Pruebas que tienen resultados predecibles | Pruebas que experimentan cambios frecuentes que requieren el mantenimiento de los casos de prueba |
| Pruebas que deben ejecutarse con frecuencia | Pruebas fáciles de realizar manualmente |
| Pruebas que ayudan a reducir la tarea manual cuando se somete a prueba la lógica compleja | Pruebas demasiado complejas para automatizarlas |
| Pruebas que contienen reglas con un amplio uso en la aplicación | Pruebas que contienen la persistencia de datos de una base de datos |
Tip: Se recomienda que ejecute las pruebas en cada fusión y registro como mínimo, pero lo ideal es que lo haga con mayor frecuencia y regularidad.
Desarrollar una cobertura
Debido a que sus pruebas unitarias abarcan una amplia variedad de escenarios, asegúrese de crear suficientes validaciones para incluir todos los escenarios positivos y negativos. Intente incluir la mayor cobertura de reglas posible, que incorpore diferentes rutas de ejecución de las reglas. Agregue suficientes pruebas que abarquen todas las combinaciones de entrada y salida, pero mantenga la lógica del caso de prueba breve y visible para optimizar la reutilización. Las pruebas unitarias más pequeñas pueden ayudar a identificar rápidamente cuando la funcionalidad de la regla no funciona y promover la facilidad en el diseño y el mantenimiento.
Nota: Para obtener más información sobre la medición de la cobertura de las pruebas de las reglas, consulte el tema Cobertura de pruebas de Academy.
Construir para el mantenimiento
Cada caso de prueba debe ser fácil de leer y entender por cualquier persona. Por ejemplo, los nombres y las descripciones de los casos de prueba son relevantes y explican el propósito del caso de prueba. Agregue comentarios para cada paso con el fin de mejorar la legibilidad y garantizar la facilidad de mantenimiento.
Haga que los datos de prueba sean lo más modulares posible para que cualquier actualización o cambio futuro sea más fácil y rápido. Por ejemplo, no es necesario crear datos de prueba para la aplicación en su conjunto o estructuras de datos más grandes y complejas. Los datos de prueba más modulares significan que los pequeños cambios no requieren la reconfiguración de todos los datos de prueba ni la posible introducción de problemas en otras pruebas.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
¿Quiere ayudarnos a mejorar este contenido?