Ejecute casos de prueba en paralelo y genere informes con la herramienta Karate

run test cases parallel generate reports using karate tool

Este tutorial explica cómo realizar algunas operaciones básicas en la API, ejecutar casos de prueba en paralelo y generar informes con Karate Framework:

Hemos aprendido cómo crear un script de prueba básico en nuestro tutorial anterior, ahora podemos seguir adelante con el aprendizaje de algunas operaciones básicas que se pueden realizar mientras se trabaja con la API y Karate Framework. Hay muchas operaciones de este tipo y discutiremos algunas de las que se usan comúnmente en este tutorial.

También profundizaremos en el proceso de ejecución de casos de prueba en paralelo siguiendo un enfoque paso a paso. También discutiremos el informe actual que se genera automáticamente y lo compararemos con el informe Cucumber que podemos generar integrando un complemento.

Lo que vas a aprender:

• Trabajar con API y herramienta de prueba de Karate
  • Realización de varias operaciones
  • Realización de operaciones posteriores
• Ejecute casos de prueba en paralelo
• Integrar el complemento Cucumber para informes
• Conclusión
  • Lectura recomendada

Trabajar con API y herramienta de prueba de Karate

Como se discutió en el tutorial anterior, en el .característica archivo que habíamos creado, podríamos usar diferentes palabras clave para realizar diferentes operaciones en la API. Kárate framework nos proporciona varias palabras clave que se pueden utilizar para realizar diversas acciones.

=> Lectura recomendada: Prueba de API con Karate Framework

Realización de varias operaciones

# 1) Imprimir la respuesta en la consola

Imprimir es una palabra clave proporcionada por Karate Framework para imprimir el resultado en la consola o en el archivo. Uno de los usos más habituales es imprimir la respuesta de la API. Esto puede resultar muy útil para el usuario.

Podemos hacer esto usando las siguientes líneas de código:

Las líneas de código anteriores darán el siguiente resultado:

Así es como podemos imprimir la respuesta de la API en la consola con el propósito de leer, la cual se puede utilizar en el momento de la depuración.

# 2) Declaración de las variables

Podemos declarar las variables usando la palabra clave def en el marco de Karate y luego use las variables declaradas en el código donde sea necesario.

En el siguiente ejemplo, hemos agregado algunas líneas más de código al existente userDetails.feature archivo para ayudar a declarar las variables en el script.

# 3) Afirmar la respuesta real a la respuesta esperada

Karate Framework ayuda a realizar las operaciones relacionadas con la afirmación utilizando el partido palabra clave. los partido es inteligente porque el espacio en blanco no le importa y el orden de las teclas no es importante.

Para usar palabra clave de concordancia, Necesitamos hacer uso del signo de doble igual '==' que representa una comparación.

Ahora trataremos de desarrollar algunos usos de partido palabra clave.

a) Cuando se menciona toda la respuesta esperada en el archivo .feature.

En determinados momentos tenemos algunos datos que nos gustaría validar inmediatamente en el propio archivo. Por lo general, este tipo de datos se mencionan al depurar el código.

Podríamos hacer lo mismo en el archivo .feature como se muestra a continuación:

Si envía una solicitud a la URL 'Https://reqres.in/api/users/2' en el navegador, luego obtendrá la siguiente respuesta:

Estamos tratando de validar la respuesta anterior usando el archivo * .feature.

Hemos utilizado el partido palabra clave proporcionada por Karate Framework, que ayuda a realizar diferentes tipos de Afirmaciones en la respuesta de la API.

Nota : Necesitaríamos transformar la respuesta de la API en una línea para realizar el paso anterior. Puede utilizar cualquiera de las herramientas disponibles en línea.

b) Cuando la salida esperada se guarda en un archivo JSON externo.

En el ejemplo anterior, discutimos un escenario en el que teníamos datos limitados y la misma respuesta que era fácil de manejar, pero en los escenarios reales, tendremos conjuntos gigantes de respuestas JSON que podríamos tener que evaluar.

Entonces, en esos casos, es mejor mantener la respuesta en el archivo externo y luego verificar la misma.

En el siguiente ejemplo, analizaremos más a fondo lo mismo:

• Necesito crear un ExpectedOutput.json archivo en nuestra carpeta Proyecto como se muestra en la imagen de abajo.

Crear un nuevo paquete de recursos -> Crear un nuevo archivo ExpectedOutput.json

Y almacene la respuesta JSON en este archivo y guárdelo.

Debería escribir el siguiente código en su userDetails.feature expediente:

En el ejemplo anterior, primero estamos leyendo el archivo ExpectedOutput.json y almacenando la respuesta de la misma en la variable Resultado Esperado utilizando la siguientes líneas de código:

Luego, colocamos la Aserción usando las siguientes líneas de código, donde estamos haciendo coincidir el Respuesta real con el Resultado Esperado respuesta con el ' ==” operador.

c) Hacer coincidir / verificar ciertos valores de la respuesta

Hasta ahora, hemos verificado la respuesta completa de la API, pero cada vez no querrá verificar la respuesta completa. A veces, le gustaría evaluar solo una parte de la respuesta. Por lo general, hacemos lo mismo cuando usamos las otras herramientas para pruebas de API o mientras creamos un marco.

Para entenderlo mejor, tomemos la siguiente respuesta JSON como ejemplo:

Si queremos verificar que el parámetro empresa debería tener el valor como StatusCode semanal, luego tendremos que crear una ruta JSON. Esto se puede hacer atravesando el archivo JSON y usando el '.' (Operador de punto)

La ruta JSON para la respuesta anterior será:

ad.company == 'StatusCode Weekly'

A continuación se muestra el fragmento de código que nos ayudará a evaluar los valores para el parámetro en particular. Este código pertenece al .característica expediente.

A continuación se muestra la línea de código, que realiza las aserciones paramétricas.

Usando la ruta JSON, estamos evaluando los valores de los parámetros.

Realización de operaciones posteriores

Hasta ahora hemos cubierto los escenarios básicos de probar una API cuando el método era ' OBTENER'. Pero cuando estamos trabajando en el entorno real, tenemos que enviar mucha información al servidor, así que en ese caso, usamos el ' CORREO' método .

Esta sección le dará una idea de cómo trabajar con la solicitud POST básica.

Obtengamos algunas ideas breves sobre los parámetros que necesitamos para enviar la solicitud POST.

# 1) Crear una solicitud POST, cuando el cuerpo JSON se menciona en el archivo * .feature

• Cree un userDetailsPost.feature utilizando los pasos similares mencionados en el tutorial anterior.
• Escribe las siguientes líneas de código:

Dado que es una solicitud POST, que siempre debe ir acompañada de un cuerpo que debe enviarse al servidor para una determinada respuesta, lo hemos mencionado en el siguiente componente:

petición: Toma un cuerpo JSON como la solicitud que se requiere con el método POST.

# 2) Crear una solicitud POST, cuando se menciona el cuerpo JSON en un archivo externo

Por lo general, tendremos un cuerpo de solicitudes enorme, que sería difícil de mencionar en el *.característica expediente. Por tanto, es mejor guardarlo en el archivo externo.

• Necesita crear un archivo PostBody.json en nuestra carpeta Proyecto como se muestra a continuación. Cree un nuevo recurso de paquete -> Cree un nuevo archivo PostBody.json y almacene el JSON Body en este archivo y guárdelo.

Nota: Hemos mencionado el cuerpo del método POST en el archivo JSON anterior.

• Debería escribir el siguiente código en su userDetailsPost .característica expediente:

Estamos leyendo el JSON Body de PostBody.json usando las siguientes líneas de código:

Nota: Todos userDeatils.feature archivos que hemos creado hasta ahora requerirán el básico TestRunner.java para ejecutarlos, que creamos en nuestro tutorial Basic Test Script como se muestra a continuación:

Ejecute casos de prueba en paralelo

Ahora, dado que hemos aprendido los pasos para crear un script de prueba básico y hemos realizado algunas operaciones básicas en la API, es hora de que comencemos a trabajar en el entorno real.

Por lo general, tenemos que ejecutar los casos de prueba en paralelo para que la ejecución sea más rápida. Básicamente, la idea es obtener más resultados en menos tiempo.

Esta es una característica central del marco y no depende de JUnit, Maven o Grade. Nos permite:

• Elija fácilmente las funciones y las etiquetas para ejecutar conjuntos de pruebas de manera sencilla.
• Vea los resultados de Parallel en la carpeta surefire-plugin.
• Incluso podemos integrar los informes JSON de Cucumber para una mejor interfaz de usuario (que se analizará en breve).

En Karate Framework, no necesitamos realizar muchos pasos, para iniciar la ejecución en paralelo de nuestros casos de prueba. Solo tenemos que seguir los siguientes pasos:

1) Ahora necesitamos cambiar el TestRunner.java archivo que hemos estado usando hasta ahora. El código para la ejecución paralela debe escribirse en el archivo anterior.

Tenga en cuenta la siguiente línea, mientras ejecuta su código en paralelo:

mejor programa para convertir archivos de video

** No podemos usar la anotación @RunWith (Karate.class) cuando intentamos trabajar en un entorno paralelo.

Abre el original TestRunner.java archivo y use el siguiente código ahora:

** El siguiente código será aplicable para Dependencia de JUnit 4 Maven

En el fragmento de código anterior, hemos incluido la siguiente línea de código:

Resultados resultados = Runner.parallel (getClass (), 5);

Esta línea indica cómo ejecutar la instancia de los casos de prueba en paralelo obteniendo las clases de forma dinámica en el tiempo de ejecución.

2) Crea un duplicado userDetails.feature archivo como se menciona a continuación en el src / test / java carpeta.

Ahora estamos listos para la ejecución paralela con 2 . caracteristicas expediente.

3) Ir TestRunner.java archivo creado en el paso anterior y ejecútelo como JUnit Test. Con esto, ejecutaremos nuestros casos de prueba en formato paralelo.

Para facilitar la lectura, Karate Framework presenta cierta información en la consola cada vez que se completa la ejecución de la prueba.

El resultado se parece al siguiente:

Con la ejecución en paralelo, todas las funciones se ejecutarán en paralelo y los escenarios también se ejecutarán en formato paralelo.

Siguiendo los pasos anteriores, podrá iniciar la ejecución paralela muy básica de la prueba API, utilizando Karate Framework.

** Puede estudiar acerca de las pruebas en paralelo recorriendo los distintos filtros de la página. Ejecución paralela

Integrar el complemento Cucumber para informes

Como estamos usando el Corredor de JUnit para la ejecución de diferentes escenarios que se han mencionado en los diferentes *.característica archivos, crea automáticamente un informe para cada uno de los archivos de características que se almacenan en la ruta informes de objetivo / infalible.

Genera un Informe básico con formato de interfaz de usuario para presentar los casos de prueba que se han ejecutado.

Sin embargo, los informes que se generan no son muy agradables en términos de interfaz de usuario, y para poder compartir informes con las partes interesadas, necesitamos algo que sea más fácil de usar y comprensible.

Para lograr este formato de informes, Karate Framework ofrece la opción de integrar Complemento de informes de pepino lo que nos ayudará a generar un informe con formato gráfico, que será más presentable.

Los siguientes son los pasos para integrar el mismo:

#1) Agregue lo siguiente Informe de pepino dependencia a su POM.xml

#2) Edite el archivo TestRunner.java cuando solo haya una *.característica archivo en el proyecto.

Necesitamos actualizar nuestro archivo TestRunner.java, con el siguiente método generateReport () para el complemento Cucumber.

En el código mencionado anteriormente, estamos realizando las siguientes acciones:

• Creando una nueva instancia de Archivo
• Proporcionar la ruta para almacenar los archivos en la carpeta de destino
• Creación de un objeto ReportBuilder que creará un nuevo informe Cucumber

Nota : El código anterior funciona bien cuando tenemos un solo *. característica archivo en nuestro proyecto.

#3) Edite el archivo TestRunner.java cuando haya múltiples * .característica archivos en el proyecto.

Necesitaríamos agregar una línea de código (resaltada en negrita a continuación) para asegurar que se cuide la ejecución paralela, mientras se ejecutan los escenarios para la generación del informe.

Después de realizar los pasos mencionados anteriormente, podremos crear con éxito un informe de IU gráfico bien representado utilizando el Pepino - informes enchufar.

Podemos encontrar el informe en la siguiente ruta de nuestro proyecto como se muestra en la imagen a continuación:

Se generó el siguiente informe para nuestro proyecto, para todas las operaciones que hemos realizado hasta ahora en este Tutorial de Karate Framework:

Conclusión

En resumen, en este tutorial hemos discutido las operaciones básicas que son útiles en el día a día mientras se trabaja con el Marco de Karate y como ejecutar varios archivos * .feature en paralelo. También aprendimos a crear un informe gráfico para los usuarios usando el Informe de pepino enchufar.

Primero, discutimos las operaciones básicas que se pueden realizar en la API. Discutimos cómo podemos enviar el cuerpo / solicitud POST al servidor, ya sea mencionando el cuerpo en el archivo * .feature en sí (que generalmente no es una práctica recomendada) o usando un archivo externo (una práctica recomendada, con el fin de mantener un código limpio).

En segundo lugar, después de seguir algunos pasos básicos, pudimos ejecutar con éxito el resultado de la prueba durante dos *.característica archivos que se ejecutaron en paralelo, simplemente agregando algunas líneas de código en el TestRunner.java archivo que permite el inicio de la ejecución paralela.

Además de esto, aprendimos cómo transformar el informe de prueba JUnit nativo en un informe de pepino integrando el Informe de pepino enchufar. El complemento nos permite generar informes que tienen una mejor interfaz de usuario, son mucho más comprensibles para el usuario y, por lo tanto, brindan una mejor experiencia de usuario a las partes interesadas con las que se comparten estos informes.

A estas alturas, debería poder realizar algunas operaciones básicas, ejecutar los casos de prueba en paralelo y generar un informe fácil de leer para los usuarios.

<