Este blog es parte de una serie de blogs, por lo que puede encontrar la primera página aquí (https://blogs.sap.com/2023/02/02/sap-cpi-ci-cd-from-from-zero-to-hero/). Esta es la agenda que estamos siguiendo:

Viniendo de un fondo de desarrollo JAVA, las pruebas automatizadas siempre fueron parte del desarrollo. Me sorprendió mucho darme cuenta de que no existen herramientas estándar con respecto a las pruebas automatizadas para sus iflows. Al hablar sobre el alcance de la integración, estoy seguro de que hay muchos tipos de pruebas que puede hacer, pero puedo pensar de inmediato en:

1. Pruebas E2E de su integración utilizando escenarios simulados
2. Pruebas de rendimiento
3. Pruebas unitarias (enfoque principal en esta página)

Pruebas E2E

Herramientas generales

Con respecto a las pruebas E2E, hay varios productos de prueba generales (p. ej., Tosca tricentis, HP ALM) que hacen un buen trabajo al permitirle proporcionar a sus interfaces datos predeterminados y afirmar algunos resultados de su API. Estas herramientas funcionan perfectamente bien si su interfaz está aislada sin dependencias de adaptadores externos, lo que significa que está totalmente bajo su control. Sin embargo, si su interfaz usa una API externa dentro de ella y necesita simularla en su prueba, entonces tendrá un problema ya que estos productos no pueden interferir con la lógica dentro de sus iflows al simular los adaptadores que está usando. .

Herramienta de prueba Figaf

Al investigar un poco, encontré la herramienta de prueba Figaf para CPI que parece ser una alternativa increíble que permite simular sus adaptadores. Si reflexiono sobre ello, es probable que sea una copia de su iflow original, pero con los puntos finales de los adaptadores reemplazados por puntos finales en una URL controlada fija donde puede inyectar su cuerpo simulado simulando una respuesta de ese adaptador, pero espero que alguien de Figaf pueda comentar sobre eso Daniel Gravesen. Tiene una cabina UI5 que le permite administrar sus casos de prueba y registrar sus casos de prueba aprovechando el modo de seguimiento en su iflow. Esto parece muy interesante ya que no necesita crear manualmente los datos de su caso de prueba. Luego puede ejecutarlo más adelante y afirmar para cada paso que no se introdujeron regresiones. Más detalles en el siguiente enlace https://youtu.be/GODYt867u8g . Nunca lo probé pero parece prometedor. te invito Daniel Gravesen o cualquier otra persona para proporcionar más detalles al respecto en los comentarios.

INT4 IFTT

INT4 también tiene una herramienta similar para probar paquetes de CPI, pero como parte de un producto más amplio que también le permite probar PI, tener integración con eCATT, etc. La cabina se instala y configura en el backend de S4 y, al final, también aprovecha el modo de seguimiento para capturar cargas útiles en el punto inicial y final configurado en su objeto de automatización. Luego puede ejecutar los casos de prueba desde la cabina y evaluar los resultados allí. Más detalles sobre la unidad 4 de la semana 3 de este curso abierto de SAP https://open.sap.com/courses/iftt1-pc . yo tambien te invito Michal Krawczyk@Andrzej.Halicki o cualquier otra persona que haya probado la herramienta para brindar más detalles al respecto en los comentarios.

Actualmente estamos evaluando Tosca, ya que ya tenemos las licencias que se adquirieron en el alcance de otros productos, pero aún no nos enfocamos en las pruebas E2E hasta ahora en el equipo de Integración.

Pruebas de rendimiento

No tengo experiencia con pruebas de rendimiento específicamente para la integración. He usado HP Load Runner y JMeter en el pasado para pruebas web generales y creo que son adecuados para probar o simular varias solicitudes al mismo tiempo. Hasta ahora, no hemos tenido la oportunidad de realizar pruebas de rendimiento en nuestras interfaces. Si ha hecho algo en esta área, proporcione sus puntos de vista en los comentarios.

Pruebas unitarias: Groovy y XSpec

No encontré nada sobre este tema, pero este fue el que pensé que podría aportar más valor al equipo, ya que está totalmente controlado por los desarrolladores, no debería tener falsos positivos ni dependencias cuando se habla de pruebas unitarias. Nuestra canalización por paquete estaba realizando algunas comprobaciones (como las comprobaciones de cpilint), por lo que parecía la canalización perfecta para mejorar y realizar pruebas unitarias automatizadas también. Más detalles sobre los pasos a continuación. Un aspecto clave que quería garantizar es que las pruebas unitarias residen dentro de los artefactos de iflow. Si mueve/copia/implementa/git sus iflows, tiene mucho sentido que sus pruebas vayan con él como una unidad. A continuación puede encontrar el diagrama de los pasos que seguimos en nuestra canalización.

Pasos de prueba unitaria

1. Extraer y 4. Ejecutar pruebas unitarias geniales

La canalización comienza con la descarga de todos sus archivos maravillosos. Para las pruebas unitarias, decidimos tener clases de prueba Groovy dedicadas y, como convención de nomenclatura, decidimos usar el sufijo UnitTest.groovy, por ejemplo, para StringUtils.groovy, podría tener un archivo StringUtilsUnitTest.groovy. Esto solo se impuso para que podamos ver claramente qué clase está probando qué, pero desde una perspectiva técnica esto no es realmente obligatorio ya que jUnit es lo suficientemente inteligente como para seguir una ruta y ejecutar todas las clases con métodos anotados con @Test.

Valor añadido

Permita agregar pruebas junit para sus clases maravillosas, asegurándose de que se ejecuten en las compilaciones de canalización. Si tiene una asignación que se basa en un script maravilloso, puede realizar una prueba unitaria y asegurarse de que devuelve los valores esperados.

2. Extraer y 3. Ejecutar XSpec

Un colega mencionó que sería genial permitir también ejecutar pruebas unitarias para XSLT, ya que también lo usamos en nuestras asignaciones. Después de investigar un poco, encontré XSpec y lo incorporé a nuestra canalización. Desafortunadamente, no puede agregar ningún archivo que desee a su iflow a través de la interfaz de usuario de Cloud Integration (solo se permiten algunas extensiones), por lo que tuve que hacer la solución para tratar de encontrar ambos archivos que terminan en *.xspec o *.xspec.xsl así que que puede agregarlos a través de la interfaz de usuario y se almacenan en su proyecto.

Ejecutamos todas las pruebas unitarias de xspec dentro de los flujos de flujo del paquete que estamos evaluando e informamos a través de junit que informa sobre jenkins.

Valor añadido

Permita realizar pruebas unitarias de sus XSLT e informar fallas en su canalización por proyecto en jenkins.

5. Generar informes jenkins

Si alguna prueba falla, lo informamos en los informes de Jenkins y la compilación falla.

Valor añadido

Permite realizar un seguimiento de la ejecución de la prueba unitaria, ver cuántas pruebas se ejecutaron, cuántas fallaron y le permite profundizar en los detalles de la interfaz de usuario de Jenkins.

5. Notificaciones por correo electrónico para el desarrollador responsable

Si alguna prueba falla, también lo informamos por correo electrónico al desarrollador responsable junto con los detalles en el cuerpo del correo electrónico.

Pruebas unitarias: asignaciones de mensajes

En nuestras integraciones, los mapeos de mensajes son nuestro mecanismo de mapeo preferido. Le permite mapear desde un editor gráfico de interfaz de usuario y es una tecnología lo suficientemente madura que proviene de los días de desarrollo de PI. Además, le permite interactuar con scripts maravillosos personalizados para mapeos más sofisticados o con funciones UDF estándar para los escenarios más comunes. Su interfaz puede fallar en muchos puntos, pero el mapeo es definitivamente una de las áreas donde podemos tener más regresiones. Por lo tanto, tuvimos que pensar en probar las asignaciones de mensajes.

1er enfoque: usar pruebas fuera de línea

Con la ayuda de los blogs de Vadim Klímov, descargué las bibliotecas karaf de nuestro inquilino. Al final, puede descargar los archivos de su arrendatario utilizando un script maravilloso que descarga archivos como muestra Vadim en sus blogs o a través de un shell inverso con el que puede interactuar a través de netcat conectando su sistema a su arrendatario. La idea era identificar el sap jar en el tiempo de ejecución de karaf responsable de realizar una ejecución de mapeo de mensajes e invocarlo a través de un programa personalizado. Esta idea era excelente ya que podía invocarla sin conexión con la necesidad de CPI, por otro lado, era bastante peligrosa ya que este no era un enfoque oficial de SAP, por lo tanto, SAP podría cambiar el jar o el enfoque más adelante y sus pruebas unitarias dejarían de funcionar. Además, creo que se genera código java para cada mapeo que diseñe y esta clase de generador java no es parte de nuestra lista de inquilinos de jars, pero si alguien ha investigado eso, hágamelo saber en los comentarios.

2do enfoque: use el tiempo de ejecución de Cloud Integration para probar sus asignaciones de mensajes

La idea era implementar un iflow dedicado que contuviera solo sus asignaciones de mensajes, así como todas las dependencias, y ejecutar este iflow dedicado para afirmar los resultados de la prueba. Así es como funciona

Pasos de las pruebas unitarias de mapeo de mensajes

1. Extraer asignaciones de mensajes

La canalización del paquete recorre cada iflow y extrae la lista de todas las asignaciones de mensajes contenidas en él, así como todos los recursos que se pueden usar dentro de él.

2. Implemente iflow dinámico

Tenemos un iflow de plantilla, que contiene solo un ejemplo de asignación de mensajes (que se reemplaza con la ejecución de la canalización) y un paso para convertir los encabezados nuevamente en propiedades.

Flujo dinámico

La idea es reemplazar las asignaciones de mensajes y las dependencias e invocar este iflow creado dinámicamente con los encabezados, las propiedades y el cuerpo y obtener un resultado. Dado que http no admite el concepto de «propiedades», necesitamos traducirlo de los encabezados proporcionados al realizar la invocación. El nombre del iflow generado contiene un prefijo, el nombre del iflow original, el nombre del mapeo de mensajes para garantizar que no haya conflictos de nombres.

3. Cambiar punto final

Nuevamente, para evitar conflictos de nombres, cambiamos el punto final a un nombre único en el objeto de diseño de iflow. Después de esto desplegamos el iflow

4. Llame al punto final generado dinámicamente

Llamamos al punto final generado dinámicamente con las propiedades, los encabezados y el cuerpo proporcionados por el desarrollador en la prueba unitaria maravillosa

5. y 6. Evaluar resultados

Usamos XMLUnit para asegurarnos de que los resultados xml no se vean afectados por espacios en blanco y finalmente comparamos el xml esperado con el resultado xml real. La limitación aquí es que no admitimos json en sus asignaciones de mensajes, hasta ahora solo admitimos xml.

7. y 8. Limpieza

Después de la ejecución, podemos anular la implementación y eliminar el iflow creado dinámicamente. Más tarde, optimizamos este paso para que la fase de preparación y la fase de desmontaje no se ejecuten a menos que se cambie el flujo de flujo que se está probando, ya que tenemos alrededor de 160 flujos de flujo flotante que contienen pruebas unitarias de mapeo de mensajes y tener este proceso de configuración/desmontaje todos los días no tiene sentido si los iflows bajo prueba no cambian.

Ejemplo de una prueba genial, asignaciones de mensajes de prueba

import FormatNumber;
import org.junit.Test;
import static org.junit.Assert.assertEquals;

class Test001_SystemSubscribeMM_MessageMappingUnitTest implements Serializable {
    public String getBody() {
		def body = """<?xml version="1.0" encoding="utf-8"?>
						<root>
						<table>
						<DummyCategory>123</DummyCategory>
						<FakeCategory>111</FakeCategory>
						<Customer>FakeCustomer</Customer>
						<Date>20211103</Date>
						<Created>20211103 10:20</Created>
						<Quantity>3</Quantity>
						<Notes>FakeNote</Notes>
						<Creator>FakeCreator</Creator>
						</table>
						</root>"""
		return body
	}
	
	public Map getProperties()
	{  
		def result = [:];
	    return result;
	}
	
	public Map getHeaders()
	{
		def headers = [SQL_Action_Command: "INSERT", SQL_Table: "FER_Table_Target"]
		return headers;
	}
	
	public Map getExpectedHeaders()
	{
		def headers = [SQL_Action_Command: "INSERT", SQL_Table: "FER_Table_Target"]
		return headers;
	}
	
	@Test
	public void testFormatNullableNumberNotNull()
	{
		def numberTestFormat = new FormatNumber();
		def result = numberTestFormat.FormatNullableNumber("4.321");
		assertEquals("Result in this case should be empty since argument is null","4.321",result);
	}
	
	@Test
	public void testFormatNullableNumberNull()
	{
		def numberTestFormat = new FormatNumber();
		def result = numberTestFormat.FormatNullableNumber(null);
		assertEquals("Result in this case should be empty since argument is null","0.000",result);
	}
	
	public String getExpectedBody()
	{
		def expectedBody = """<?xml version="1.0" encoding="UTF-8"?>
<root><StatementName1><dbTableName action="INSERT"><table>FER_Table_Target</table><access><DUMMYCATEGORY>123</DUMMYCATEGORY><FAKE_CATEGORY>111</FAKE_CATEGORY><CUSTOMER>FakeCustomer</CUSTOMER><ENTERED_DATE>2021-11-03 00:00:00.000</ENTERED_DATE><QUANTITY>3.0</QUANTITY><CREATION_DATE>2021-11-03 10:20:00.000</CREATION_DATE><NOTES>FakeNote</NOTES><CREATION_SOURCE>FakeCreator</CREATION_SOURCE></access></dbTableName></StatementName1></root>""";
		return expectedBody;
	}

}

• obtenercuerpo contiene la carga útil del cuerpo que se inyectará en el iflow creado dinámicamente
• obtener propiedades contiene un mapa de propiedades de valor clave que podría esperar su asignación de mensajes y que se proporcionará al llamar a la asignación de mensajes
• getHeaders contiene un mapa de encabezados de valor clave que podría esperar su asignación de mensajes y que se proporcionará al llamar a la asignación de mensajes
• getExpectedHeaders contiene un mapa de encabezados esperados que estarán presentes al final. Si esta lista está vacía, no se aplica ninguna verificación en los encabezados
• obtenerCuerpoEsperado contiene el cuerpo de carga esperado resultado de llamar al iflow dinámico
• Los métodos @Test solo están ahí para ilustrar que también puede hacer otras pruebas unitarias regulares como parte de la misma clase si lo desea.

En este tema, introduje el tema de las pruebas automatizadas, presentando algunas de las herramientas que hemos investigado, así como la solución elegida para realizar pruebas unitarias automatizadas a través de jenkins.

También te invito a compartir algunos comentarios o pensamientos en las secciones de comentarios. Estoy seguro de que todavía hay mejoras o ideas para nuevas reglas que beneficiarían a toda la comunidad. Siempre puede obtener más información sobre la integración de la nube en el página de tema para el producto