“Procesar mensajes seleccionados” y verificar que mi escenario con receptor ficticio funciona. El procesamiento a través de la canalización generará un intercambio de mensajes PIT válido con una versión de intercambio de mensajes entrantes y salientes.
“Crear nuevo conjunto de datos de prueba”.
Hacia el desarrollo basado en pruebas con la herramienta de prueba de integración de procesos de SAP
By s4pcademy
Desarrollo basado en pruebas es un concepto en la práctica de desarrollo de software, donde el desarrollo de software se sigue de cerca mediante la ejecución repetida de pruebas. En su forma pura, las pruebas deben existir incluso antes que el propio software.
En esta publicación de blog, le mostraré paso a paso cómo Process Integration Test puede brindarle un paso hacia el desarrollo basado en pruebas mientras desarrolla un nuevo flujo de integración. Incluso si no se puede alcanzar una forma pura de desarrollo basado en pruebas con los medios actuales disponibles en PIT, el procedimiento lo ayudará a lograr una mejor calidad a través de una alta cobertura de pruebas y evitando errores en la etapa más temprana del proceso de desarrollo.
Supongamos que quiero desarrollar un nuevo flujo de integración con condiciones de enrutamiento complejas. Para asegurarme de que formulé todas las condiciones correctamente y que el enrutamiento funciona como se esperaba, quiero tener un mensaje de prueba para cada ruta de condición diferente. Como mi flujo de integración aún no es productivo, no tengo ningún remitente que pueda enviar mensajes regulares y aunque no puedo extraer mensajes de prueba en un conjunto de datos de prueba en PIT.
Comienzo desde el principio en la perspectiva de Integration Designer en NWDS y creo un nuevo flujo de integración, que tiene solo un receptor ficticio predeterminado y aún no tiene condiciones. Activo y despliego el flujo de integración.
Figura 1: Flujo de integración inicial, aún sin condiciones y con receptor ficticio
Inmediatamente después, puedo crear un nuevo caso de prueba PIT directamente desde la perspectiva de Integration Designer. Selecciono el flujo de integración, elijo «Crear caso de prueba» en el menú contextual y sigo los pasos en el mago. Un requisito previo para el asistente de generación es que se mantenga una conexión con el sistema PIT deseado en la perspectiva Prueba de integración de procesos y que ya exista una entidad de sistema de prueba adecuada (crucial: el nombre del sistema de prueba en PIT debe ser igual al nombre del sistema en Diseñador de integración). Selecciono la casilla de verificación en el último paso del asistente para el cambio automático a la perspectiva de ‘Prueba de integración de procesos de SAP’.
Figura 2: Cree un nuevo caso de prueba PIT a partir del flujo de integración
En la perspectiva Prueba de integración de procesos, el caso de prueba se agrega al Catálogo de prueba y el editor se abre automáticamente. Pero en lugar de extraer los intercambios de mensajes del sistema a un conjunto de datos de prueba (recuerde, todavía no hay mensajes adecuados en el sistema), los crearé manualmente usando banco de trabajo de borrador de datos de prueba. Más tarde, puedo crear un conjunto de datos de prueba que contenga estos mensajes y asignarlo al caso de prueba.
Figura 3: Caso de prueba creado por el asistente que se muestra en la perspectiva PIT
Con la ayuda del banco de trabajo de borrador de datos de prueba, puedo crear muchos intercambios de mensajes de prueba diferentes para el flujo de integración y proporcionar una carga útil adecuada para cada condición de XPath y probar el flujo de integración a lo largo del proceso de desarrollo.
Abro la descripción general del borrador de datos de prueba (en la perspectiva NWDS Prueba de integración de procesos de SAP seleccione el menú Integración de procesos -> Descripción general del borrador de datos de prueba) y seleccione «Crear nuevo borrador de datos de prueba» en la barra de herramientas. Proporciono un nombre para el borrador de datos de prueba y le asigno mi flujo de integración. Una vez que se confirme el cuadro de diálogo, el editor ‘Test Data Draft Workbench’ se abrirá automáticamente.
Figura 4: asistente ‘Crear borrador de datos de prueba’
En el banco de trabajo del borrador de datos de prueba, agrego mi primer borrador de intercambio de mensajes manualmente usando Agregar borrador de intercambio de mensajes -> Crear nuevo e inserto mi carga útil existente como contenido.
Figura 5: asistente ‘Crear nuevo borrador de intercambio de mensajes’
El nuevo borrador de intercambio de mensajes se muestra en la lista, su contenido se carga y se puede editar, si es necesario.
Figura 6: Borrador de intercambio de mensaje ‘Nuevo’ en el banco de trabajo de borrador de datos de prueba
Figura 7: Mensaje procesado con éxito
En mi flujo de integración dirigido, el mensaje entrante se asignará a diferentes interfaces e irá a diferentes receptores según el contenido de la carga útil. Si ninguna condición puede evaluarse como verdadera, se generará un mensaje de error. La primera condición para el receptor REC_1_PRD tiene el siguiente aspecto:
Figura 8: Primera condición en el flujo de integración
Para cubrir todas las rutas posibles, necesitaré tres borradores de intercambio de mensajes de prueba diferentes para probar la primera condición. Dos borradores de intercambio de mensajes son para ambas partes ‘O’ de la condición, que espero que se procesen correctamente. El borrador del tercer intercambio de mensajes no coincide con la condición y, por lo tanto, dará como resultado un error.
Creo borradores de intercambio de mensajes adicionales copiando mi primer borrador de intercambio de mensajes (Agregar borrador de intercambio de mensajes -> Nuevo por copia) y modifico el contenido de los tres borradores según mi condición. Cambio el nombre de cada borrador de intercambio de mensajes, para que pueda reconocer más fácilmente qué mensaje cubre qué constelación.
Figura 9: Tres borradores de intercambio de mensajes para cubrir la condición
Recuerde, como mi flujo de integración ficticio aún no tiene condiciones (consulte la figura 1), los tres borradores de intercambio de mensajes se realizarán correctamente cuando se procesen de inmediato. Sin embargo, esto no es lo que quiero lograr.
Por lo tanto, vuelvo a Integration Designer y modifico mi flujo de integración. Elimino el receptor ficticio, en su lugar, el mensaje irá al receptor REC_1_PRD. Y mantengo la condición mencionada en la figura 8. En caso de que ninguna condición pueda evaluarse como verdadera, el mensaje fallará con error. Activo e implemento el flujo de integración modificado.
Figura 10: Primera condición + receptor en el flujo de integración
De vuelta en la perspectiva Prueba de integración de procesos, proceso los tres mensajes que preparé en el paso anterior y obtengo el resultado que se muestra en la figura 11. Como era de esperar, dos mensajes se procesan correctamente y el tercer mensaje falla con un error, ya que ningún receptor fue encontrado.
Figura 11: Mensajes para el primer receptor después del procesamiento
A continuación, voy a crear dos nuevos conjuntos de datos de prueba ‘Ruta a PRD1: éxito’ (que contiene mensajes exitosos) y ‘Ruta a PRD1: error’ (que contiene mensajes de error) para el primer receptor REC_1_PRD que usa mis mensajes. Decidí crear dos conjuntos de datos de prueba con solo mensajes exitosos y erróneos en lugar de un conjunto de datos de prueba mixto (que también es posible), porque luego me gustaría ejecutar una prueba positiva y negativa.
Figura 12: Crear un nuevo conjunto de datos de prueba
Los conjuntos de datos de prueba se agregan al caso de prueba y se pueden usar en configuraciones de ejecución.
Figura 13: Dos conjuntos de datos de prueba creados a partir del banco de trabajo de datos de prueba
Para poder ejecutar una prueba en PIT, necesito una configuración de ejecución. Creo dos configuraciones de ejecución: una para prueba positiva y otra para prueba negativa utilizando los conjuntos de datos de prueba anteriores. En la prueba negativa, me gustaría no solo comprobar que el mensaje falla, sino también que el mensaje falla en el paso de ENRUTAMIENTO (se marca ‘Verificar expectativa de error’).
Figura 14: Crear configuraciones de ejecución, que usan conjuntos de datos de prueba creados previamente
Ejecuto mis configuraciones de ejecución y espero que su ejecución sea exitosa. Sin embargo, la primera ejecución de “Receiver PRD OK” falla debido a las diferencias en los campos Id y usedSince, cuyo contenido se genera por mapeo y siempre diferirá entre las ejecuciones. Por lo tanto, debo agregar exenciones para que el escenario se ejecute correctamente.
Figura 15: El escenario requiere exención antes de tener éxito (exención para Id ya definida)
Utilizo el asistente «Agregar exención de verificación», que me ayuda a agregar una nueva exención fácilmente. Me sugiere que agregue un XPath basado en los resultados de la verificación. Termino el asistente y guardo el caso de prueba con la exención añadida.
Figura 16: asistente ‘Agregar exención de verificación’
Con la exención, la prueba positiva se puede ejecutar con éxito.
Figura 17: Ejecución exitosa de prueba positiva después de agregar exención y prueba negativa exitosa
Además, mi prueba negativa tiene éxito con el resultado esperado (es decir, falla con un error en el paso ‘Enrutamiento’) como se ve en la figura 17.
Estas configuraciones de ejecución se pueden ejecutar después de cada iteración en el proceso de desarrollo, por ejemplo, cuando se agrega una nueva condición o un nuevo receptor. Pero, además, puedo recopilar todas las configuraciones de ejecución en un conjunto de pruebas y ejecutarlas cómodamente en una base programada.
Creo un nuevo conjunto de pruebas y le asigno mi caso de prueba. Los conjuntos de pruebas son visibles en el catálogo de pruebas, si se selecciona ‘Suite de pruebas’ como elemento de nivel superior.
Figura 18: Nuevo conjunto de pruebas
En cuanto a los casos de prueba, PIT requiere una ‘Configuración de ejecución de la suite de pruebas’ como entidad ejecutable. Contiene un conjunto de configuraciones de ejecución de casos de prueba. Asigno mis dos configuraciones de ejecución disponibles a la configuración de ejecución del conjunto de pruebas.
Figura 19: configuración de ejecución del conjunto de pruebas como entidad ejecutable
Ahora, puedo programar la configuración de ejecución de mi conjunto de pruebas para una ejecución regular, por ejemplo, diaria. Esto me permitirá un seguimiento continuo de mi proceso de desarrollo y garantizará que mis cambios no tengan efectos secundarios que dañen involuntariamente otras condiciones. También asigno una configuración de alerta a la tarea programada, de modo que se me notifique en caso de fallas y, por lo tanto, no tenga que verificar cada ejecución manualmente.
Figura 20: Crear tarea programada para ejecución diaria
La tarea programada es visible en la vista ‘Tareas programadas’ (Ventana -> Mostrar vista -> Tareas programadas). Desde esta vista puedo saltar al Registro de acciones y mostrar todas sus ejecuciones de un vistazo (menú contextual ‘Mostrar registro de acciones’) como se muestra en la Figura 21.
Figura 21: vista de tareas programadas
Afortunadamente, mi prueba también se ejecuta con éxito como una ejecución de conjunto de pruebas programada.
Figura 22: Registro de acciones que muestra todas las ejecuciones de la tarea programada
Por lo tanto, puedo continuar con mi desarrollo y agregar más receptores, cada uno con su propia condición. Si repito los pasos a continuación para cada receptor y cada condición, con el tiempo recopilaré una buena lista de configuraciones de ejecución adecuadas para cada ruta posible. Ejecutado después de cada iteración o de forma regular, me permitirá reconocer errores rápidamente, me dará la confianza de que el escenario está configurado correctamente y mejorará la calidad.
En esta publicación de blog, describí paso a paso cómo puede mejorar el proceso de desarrollo de su escenario de PI (usando el ejemplo del desarrollo de flujo de integración) utilizando la mayoría de las funciones disponibles en SAP Process Integration Test. Este procedimiento lo ayudará a dar un paso hacia el desarrollo basado en pruebas, para lograr una alta cobertura de pruebas y mejorar la calidad de su proceso de desarrollo.
Encuentre más sobre PIT en Portal de ayuda de SAP y nuestras entradas de blog en el “PIT – Novedades» serie.
