Para los desarrolladores que han creado su propia instrumentación con el complemento Java Agent , la siguiente fase del proceso es la prueba de regresión. Al realizar pruebas de regresión, puede asegurarse de que su complemento funcione de la manera en que se supone que debe hacerlo después de realizar cambios o actualizaciones en el código. 

Tendrá su propio complemento, pero para ilustrar las pruebas de regresión en este artículo, usaré el complemento en nuestro repositorio de ejemplo .

La secuencia normal de actividad con un plugin

Primero, entendamos la secuencia normal de actividad cuando la aplicación se inicia con el Agente Java de Elastic APM (supervisión del rendimiento de la aplicación) y el complemento, usando la opción -javaagent en la línea de comando (Hay varias formas de adjuntar el agente . Para esto secuencia, supongamos la opción recomendada -javaagent ).

1. Se inicia la máquina virtual Java (JVM)

2. El agente está cargado

3. El agente carga el plugin.

4. Las clases de aplicación están cargadas.

5. El agente instrumenta la aplicación

6. La aplicación ejecuta un código que ejercita los métodos instrumentados.

7. El agente captura la información que proporciona la instrumentación

8. El agente se comunica con el servidor APM, enviando la información capturada del método instrumentado

9. Puede ver los rastros y la información en Elastic APM

Queremos validar que la información recopilada por el agente es efectivamente la esperada por la prueba. Lo que necesitamos para las pruebas es algún mecanismo que proporcione la información que captura el agente, pero que también sea accesible en la prueba en lugar de en Elastic APM. 

Hay muchas maneras de abordar eso; por ejemplo, podríamos burlarnos del agente y enviar la información a la prueba. Pero sabiendo que la comunicación entre el agente y el servidor APM es JSON simple sobre HTTP, una opción más fácil es simular el servidor APM . Con un servidor de APM simulado, es sencillo capturar la información enviada por el agente y comprobar que contiene los resultados esperados de la instrumentación y la ejecución de la prueba.

[Artículo relacionado: Supervisión del rendimiento de Elastic Enterprise Search con Elastic APM ]

La secuencia de prueba de la actividad.

Con nuestro servidor APM simulado, la secuencia de actividad para ejecutar pruebas es muy similar a la secuencia anterior, pero los últimos pasos cambian de la inspección manual de la información en Elastic APM a la inspección automatizada por parte de la prueba.

1. La JVM comienza

2. El agente está cargado

3. El agente carga el plugin.

4. Las clases de prueba de la aplicación están cargadas.

5. El agente instrumenta la aplicación

6. La aplicación ejecuta un código de prueba que ejercita los métodos instrumentados.

7. El agente captura la información que proporciona la instrumentación

8. El agente se comunica con un servidor APM simulado, enviando la información capturada por el método instrumentado

9. La prueba accede a la información del servidor APM simulado

10. La prueba valida que la información es la esperada

Implementación del marco de prueba

Analicemos esos pasos con más detalle para decidir cómo crear un marco de prueba que ejecute una prueba de regresión.

1. Se inicia la JVM. Esto lo inicia el marco de prueba habitual (supongamos que JUnit), por lo que no hay nada específico que hacer aquí.

2. El agente está cargado. Nos gustaría especificar la opción -javaagent , pero en esta etapa la JVM ya se inició, por lo que es demasiado tarde. Pero no se preocupe: el agente Java de Elastic APM tiene opciones alternativas de conexión de agentes , y el mecanismo ElasticApmAttacher.attach() es perfecto aquí. Hay un pequeño inconveniente: debemos especificar la URL del servidor APM para el agente, por lo que primero debemos iniciar el servidor APM simulado. En consecuencia, nuestros pasos aquí son:

1. Inicie el servidor APM simulado

2. Obtenga el puerto (asignado por el sistema válido) en el que comenzó

3. Establezca la propiedad server_url en localhost en ese puerto

4. Inicie el agente usando ElasticApmAttacher.attach()

5. (Esta es exactamente la secuencia implementada en AbstractInstrumentationTest.startApmServerAndSetAgentPropertiesAndStartAgent() )

3. El agente carga el complemento. Debido a que esta es una prueba de regresión en el proyecto, podemos usar el jar generado por la compilación, que se encuentra en el directorio "objetivo" del proyecto. Estamos construyendo el jar completo con todas las dependencias en el proyecto, por lo que el jar se puede usar como un complemento (no importa qué nombre tenga el jar, por lo que los cambios en la versión de compilación no son importantes). Sin embargo:

1. Maven ejecutaría pruebas en la siguiente secuencia con una compilación normal: 

1. Construye el jar simple (sin dependencias)

2. Ejecutar pruebas unitarias

3. Cree el jar del complemento de destino (jar-with-dependencies)

4. Ejecutar pruebas de integración

2. Entonces, trabajando con maven, nuestros pasos reales aquí son:

1. No es necesario construir el frasco simple

2. No use pruebas que no sean de integración

3. Dígale al agente que busque en el directorio "objetivo" el contenedor del complemento (esto se hace usando la opción de configuración plugins_dir en AbstractInstrumentationTest.startApmServerAndSetAgentPropertiesAndStartAgent() )

4. Asegúrese de que solo ejecutamos las pruebas de regresión del complemento después de generar el jar con dependencias, es decir, en las clases de prueba de integración, las clases que terminan en TI (archivos "*IT.java")

4. Se cargan las clases de prueba de la aplicación. Esto sucede normalmente cuando se ejecuta la prueba.

5. El agente instrumenta la aplicación. Esto debería suceder normalmente cuando se ejecuta la prueba, pero lo comprobaremos cuando validemos la información enviada por el agente.

6. La aplicación ejecuta un código de prueba que ejercita los métodos instrumentados. Esto debería suceder normalmente cuando se ejecuta la prueba, pero lo comprobaremos cuando validemos la información enviada por el agente.

7. El agente captura la información que proporciona la instrumentación. Esto debería suceder normalmente cuando se ejecuta la prueba, pero lo comprobaremos cuando validemos la información enviada por el agente.

8. El agente se comunica con un servidor APM simulado, enviando la información capturada por el método instrumentado. Esto debería suceder y lo probaremos, pero aquí hay una condición de carrera. El agente se comunica con el servidor APM de forma asíncrona (para no retrasar en absoluto la aplicación). Aunque se trata de una conexión de bucle invertido local, todavía hay un ligero retraso y también un posible retraso de procesamiento por lotes. Así que tenemos que hacer un par de cosas aquí:

1. Minimice cualquier retraso en el procesamiento por lotes de la comunicación entre el agente y el servidor de APM configurando api_request_size en un valor pequeño (esto se hace en AbstractInstrumentationTest.startApmServerAndSetAgentPropertiesAndStartAgent() )

2. Esté preparado para esperar un poco para recuperar la información del servidor APM simulado (agregando un tiempo de espera para recuperar la información, vea el método MockApmServer.getAndRemoveTransaction() )

9. La prueba accede a la información del servidor APM simulado.

10. La prueba valida que la información es la esperada. El servidor APM simulado devuelve la información en formato JSON, por lo que se puede navegar fácilmente por cualquier información para verificarla.

     

Poniendolo todo junto

La prueba de regresión en el repositorio que contiene el ejemplo contiene tres clases que, entre ellas, implementan el marco de prueba y las pruebas de integración. Son clases pequeñas y fáciles de entender:

• MockApmServer es solo un servidor web que intentará convertir las líneas de texto entrantes en objetos JSON. Si encuentra un objeto JSON con un nodo raíz llamado "transacción", almacenará el nodo en una matriz a la que puede acceder cualquier cosa que contenga una referencia al objeto del servidor APM simulado (es decir, subclases de AbstractInstrumentationTest ).
• AbstractInstrumentationTest proporciona la base para una prueba de integración, iniciando el servidor APM simulado y adjuntando el agente elástico, usando todas las propiedades correctas necesarias (y cerrándose correctamente cuando se completa la prueba de integración).
• ExampleHttpServerInstrumentationIT es la prueba de integración concreta que ejecuta el conjunto de pruebas completo para el complemento mediante:
  • Iniciar la aplicación
  • Ejecutar algunas solicitudes (HTTP) contra el servidor de aplicaciones
  • Verificar que las solicitudes de prueba generen el número correcto de transacciones APM elásticas válidas con los valores que corresponden a los que está configurando la instrumentación.
• Un pom lo pone todo junto, compilando y ejecutando el conjunto de pruebas en una compilación (por ejemplo, con mvn clean install ).

También puede ejecutar las pruebas desde un entorno de desarrollo integrado (IDE) como de costumbre, aunque es posible que el IDE no genere el jar con dependencias automáticamente, por lo que es posible que deba configurarse o compilarse externamente.

Pruébalo

Simplemente clone el repositorio de ejemplo , cd en el directorio raíz del proyecto y ejecute mvn clean install . Si su prueba valida que la información era la esperada, ¡entonces está listo para comenzar!

El mejor lugar para comenzar con Elastic APM es la nube. Comienza hoy tu prueba gratuita de 14 días de Elastic Cloud .