wiremock tutorial introduction wiremock
Este video tutorial introductorio explicará las características de Wiremock y cómo ejecutar Wiremock como un servidor independiente y como parte de las pruebas de JUnit:
En este tutorial, cubriremos los conceptos básicos y los detalles de la herramienta Wiremock. Se puede utilizar como servidor HTTP independiente, así como dentro de las pruebas JUnit según los requisitos.
Esta es una herramienta muy utilizada ya que es de código abierto y tiene una gran comunidad de contribuyentes. Se incluye en la categoría de herramientas de virtualización de servicios.
Lo que vas a aprender:
- ¿Qué es Wiremock?
- Conclusión
¿Qué es Wiremock?
En términos simples, Wiremock es una configuración de burla para las pruebas de integración. Es simplemente un servidor simulado que es altamente configurable para devolver una respuesta esperada para una solicitud determinada.
Se usa ampliamente durante el desarrollo y, lo que es más importante, durante las pruebas de integración, mientras que un sistema o servicio habla con una o varias dependencias / servicios externos o internos.
Intentemos comprender más sobre las pruebas de integración en general y conozcamos cómo Wiremock puede ayudarnos a superar esos desafíos y hacernos la vida más fácil.
Generalmente, cuando llega la palabra integración, lo que nos llama la atención es una integración de extremo a extremo entre 2 sistemas de comunicación. Ahora, veámoslo desde la perspectiva de una aplicación bajo prueba que utiliza algún servicio externo para realizar el trabajo.
Por ejemplo, Supongamos que estamos creando una aplicación para viajes en línea o un sistema de emisión de boletos y tenemos un módulo para verificar el estado del PNR, que llega a una API externa proporcionada por Indian Railways.
Ahora, ¿cómo podemos probar la integración de nuestra aplicación con las API externas?
Hay 2 formas de hacer esto:
- Primero, es el enfoque de prueba unitaria, donde almacenamos la interfaz que se proporciona (o se crea internamente) para que nuestro sistema pruebe / valide la respuesta falsa o insertada incluso antes de acceder a la API externa. Esto no es más que una prueba unitaria que intenta simular una dependencia externa.
- Segundo está probando con algún entorno de prueba (o el entorno de producción real) de las dependencias externas. Sin embargo, existen varios desafíos con ese enfoque, como se menciona a continuación:
- Es posible que los sistemas de API externos no siempre estén disponibles. es decir, dependemos en gran medida o dependemos de sistemas externos y cualquier tiempo de inactividad afectará nuestras pruebas e indirectamente el proceso de desarrollo / lanzamiento.
- En segundo lugar, las API externas pueden tener o no un entorno de prueba. Por ejemplo, Una API de verificación de estado de PNR siempre puede requerir números de PNR reales para obtener y devolver respuestas.
- Muchas veces, hay costos involucrados en utilizar una API. Por ejemplo, supongamos que la API de verificación del PNR cobra 100 rupias por cada 1000 solicitudes. Como las pruebas de integración generalmente se ejecutan durante cada regresión (y la mayoría de las veces con cada confirmación), puede que no sea una solución rentable alcanzar una API que nos cuesta incluso para fines de prueba.
- No se puede configurar una API externa para que devuelva la respuesta deseada. Incluso si es posible, tendrá que crear una gran cantidad de datos de prueba para garantizar diferentes respuestas para diferentes entradas de solicitud.
Por ejemplo, desea probar escenarios de error como una API que devuelve diferentes códigos de estado para diferentes tipos de datos. Ahora que la respuesta no está bajo nuestro control, necesitaremos crear múltiples conjuntos de datos para validar diferentes escenarios o resultados posibles.
Comprendamos estos conceptos con la ayuda del siguiente diagrama.
Aquí estamos comparando ambos enfoques de las pruebas de integración, es decir, sin un servidor simulado utilizando una implementación real de la dependencia externa y utilizando el servidor simulado (Wiremock) que simula las respuestas a las solicitudes recibidas para la dependencia.
En el último caso, reduce en gran medida la dependencia y la dependencia de la implementación real de la dependencia y brinda muchas capacidades de configuración sin comprometer la calidad y los programas de entrega.
¿Cómo responde Wiremock a una solicitud determinada?
Como sabemos, Wiremock es un servidor simulado programático, la forma en que responde a una solicitud determinada es almacenando todas las asignaciones relevantes (o respuestas simuladas) en una carpeta denominada 'asignaciones'
Hay un componente de emparejamiento de Wiremock que hace coincidir las solicitudes entrantes con las asignaciones almacenadas y, si se devuelve una coincidencia exitosa, la primera coincidencia se devuelve como respuesta a la solicitud dada.
En caso de que esté utilizando la versión independiente de Wiremock, una vez que ejecute el servidor Wiremock, verá la carpeta de asignaciones que se creará en el directorio de ubicación de instalación / jar de Wiremock.
Tutorial de vídeo: Introducción a la herramienta Wiremock
que es un error en el software
¿Cómo utilizar Wiremock?
Ahora veamos cómo podemos usar esta herramienta con nuestras pruebas de integración.
Se puede utilizar de las siguientes formas.
Un servidor Wiremock independiente
Como servidor independiente, puede crear una aplicación Java simple con dependencia de Maven / Gradle para Wiremock y mantenerla como un proceso en ejecución.
Esta es una buena alternativa cuando desea alojar su servidor independiente en alguna máquina y usarlo como un único servidor simulado para todo el proyecto o equipo. En modo autónomo, esta herramienta también se puede ejecutar, descargando el jar autónomo disponible aquí y simplemente ejecute el tarro.
Por ejemplo, suponga que desea implementar su instancia independiente de Wiremock en algún servidor en la nube o en un servidor local, entonces puede simplemente ejecutar este jar y usar la IP del sistema para usarlo como un servicio alojado.
Veamos algunos pasos para ejecutar esto en modo independiente (y configurar diferentes cosas como puertos, carpetas de mapeo, etc.)
#1) Ejecute el jar de Wiremock desde la terminal (o el símbolo del sistema para usuarios de Windows) como cualquier otro archivo JAR (desde el directorio de instalación del jar de Wiremock).
|_+_|#2) De forma predeterminada, Wiremock se ejecuta en localhost: 8080 (si el puerto está libre para su uso, el comando anterior iniciará el servidor Wiremock en un modo independiente) y verá la salida como se muestra a continuación.
#3) Ahora, una vez que se inicia el servidor, puede visitar cualquier URL en localhost: 8080
Por ejemplo, http: // localhost: 8080 / get / user / 1 - Como actualmente no se están configurando simulaciones, obtendrá una respuesta como se muestra a continuación.
#4) Ahora intentemos configurar un código auxiliar / simulacro simple para esta URL e intentemos devolver la URL nuevamente. Luego validaremos que al presionar la misma URL ahora se devuelve la respuesta falsa o falsa.
|_+_|Primero intentemos comprender esta solicitud CURL:
- Estamos haciendo una solicitud CURL POST a http: // localhost: 8080 / __ admin / mappings / new - Ahora, esta es la ubicación donde se almacenarán todas las asignaciones para el servidor Wiremock que ejecutamos / iniciamos a través del archivo JAR.
- En la solicitud Curl, estamos definiendo parámetros de solicitud como: URL y método de solicitud junto con el cuerpo de la respuesta en la sección 'respuesta'. Esto simplemente implica que siempre que llegue una solicitud GET con URL / get / user / 1, responda con el cuerpo de respuesta especificado.
#5) Una vez que se establece la respuesta cortada (con la ayuda de la solicitud de curl anterior), podemos intentar presionar la URL y ver si estamos obteniendo una respuesta cortada de Wiremock.
Intentemos acceder a esta URL en el navegador: http: // localhost: 8080 / get / user / 1
Si la asignación se configuró correctamente, debería obtener una respuesta como se muestra a continuación:
Junto con las pruebas de JUnit como configuración de reglas de JUnit
El servidor Wiremock se puede usar con pruebas JUnit como configuración de regla JUnit. Con esto, JUnit se encarga del ciclo de vida de Wiremock, es decir, Wiremock se inicia y se detiene.
mejor sitio para descargar videos de youtube
Se utiliza principalmente en configuraciones en las que le gustaría iniciar y detener el servidor después de cada prueba.
Esto tiene sus propias ventajas de estar aislado y tiene un alto grado de configurabilidad en comparación con una configuración independiente en la que varias personas pueden terminar usando el mismo servidor y pasar por encima de las respuestas stubped de las demás.
Veamos un ejemplo práctico de este enfoque:
#1) Cree una regla JUnit para el servidor Wiremock. Este paso es esencialmente como un paso de configuración de prueba en el que le decimos al corredor JUnit que cree una instancia del servidor Wiremock antes de cada prueba y detenga el servidor después de cada prueba.
Lo que esto también significa es que JUnit runner se encargará de iniciar y detener el servidor Wiremock, sin hacerlo explícitamente.
|_+_|#2) Ahora escribiremos nuestra prueba donde primero crearemos nuestro cliente (usando okHttp) para ejecutar solicitudes contra el punto final deseado.
|_+_|#3) Pero, puede observar aquí que todavía no hemos configurado ningún código auxiliar para que se devuelva para nuestra instancia de Wiremock. es decir, el cliente anterior solicitará una URL http: // localhost: 8080 / test / abc que no tiene ningún código auxiliar configurado. En este caso, el servidor Wiremock devolverá un 404 sin contenido.
#4) Ahora, para establecer un código auxiliar para la URL anterior para nuestra instancia de servidor Wiremock, tendremos que llamar a los métodos estáticos de código auxiliar de Wiremock como se muestra a continuación.
|_+_|Aquí, puede ver que hemos usado un par de métodos estáticos como configureFor, stubFor, etc. Todos estos métodos son parte de la biblioteca Wiremock Java. (Veremos estos métodos en detalle en nuestro próximo tutorial / secciones)
#5) Ahora, con el paso de configuración hecho, podemos simplemente ejecutar la solicitud a través del cliente y validar la respuesta (dependiendo de lo que esté configurado para que el stub regrese a través de Wiremock)
En resumen, así es como se vería la muestra de código completa:
|_+_|Dependencias requeridas
Está disponible como:
- Un JAR independiente que contiene solo la dependencia Wiremock.
- Un frasco gordo que contiene Wiremock y todas sus dependencias.
Ambos sabores están disponibles como dependencias de Gradle y Maven. Más detalles están disponibles en el repositorio oficial de Maven aquí
Video tutorial: Wiremock con prueba JUnit
Conclusión
En este tutorial, analizamos las características básicas de Wiremock y vimos cómo se puede ejecutar como un servidor independiente y como parte de las pruebas de JUnit usando las reglas de JUnit.
También mencionamos brevemente el stubbing y lo cubriremos en detalle en nuestro próximo tutorial.
SIGUIENTE Tutorial
Lectura recomendada
- Introducción a Micro Focus LoadRunner: prueba de carga con el tutorial n. ° 1 de LoadRunner
- Tutorial de Ngrok: una breve introducción con la instalación y configuración
- Tutorial de TestNG: Introducción al marco de TestNG
- Introducción a Selenium WebDriver - Tutorial de Selenium n. ° 8
- Introducción al lenguaje de programación Java - Tutorial en vídeo
- Proceso de introducción e instalación de Python
- Qué es Unix: una breve introducción a Unix
- Tutorial de Neoload: Introducción, descarga e instalación de Neoload