Muchos usan SoapUI para probar tanto la propia API como las aplicaciones que acceden a la API. Una herramienta bastante flexible que permite, por ejemplo, exportar un
archivo API swagger y generar un servicio simulado basado en él.
No hace mucho tiempo, en nuestra empresa, me enfrenté a un problema similar, pero con condiciones no triviales. Datos iniciales: es necesario probar una aplicación de servidor que recibe una tarea como entrada; durante la ejecución, se refiere a la API; cada solicitud posterior depende de la respuesta de la API. La lógica está incrustada en la aplicación. Es decir, una especie de recuadro negro donde necesita probar muchas salidas del guión, cuando solo hay una entrada al guión.
A continuación, propongo un ejemplo de una solución que le permitió integrarse fácilmente en una infraestructura de regresión, además de tener un margen para escalar, en caso de aumentar la cobertura del rango de escenarios y su complejidad.
Primero, cree un servicio simulado en SoapUI. Esto se hace con unos pocos clics:
Ahora pasemos a crear apéndices para consultas. Como solo hay una entrada en el script en la tarea, tenemos opciones:
- use el identificador del script y páselo en cada solicitud, y en cada trozo determine la respuesta dependiendo de este identificador;
- especifique de antemano una lista de respuestas para cada código auxiliar y almacénelas en variables globales antes de ejecutar la prueba.
La primera opción se puede usar cuando es necesario recibir una respuesta del apéndice para varias solicitudes al mismo tiempo. La implementación requiere que la aplicación del cliente pueda transmitir un identificador específico en cada solicitud de API. En nuestro caso, esto era prácticamente imposible, y no se requerían pruebas simultáneas de varios escenarios, por lo que se eligió la segunda opción.
Entonces, para asignar una lista de respuestas de código auxiliar, ejecutamos la siguiente consulta antes de ejecutar la prueba:
Post: http:
En el servicio Mock, agregamos el procesamiento de solicitud "SetScenario". Solo tiene dos respuestas: "200_OK" si la solicitud entrante se procesó correctamente y "400_BadRequest" si la solicitud se realizó incorrectamente:
En el script, distribuimos los valores de respuesta para los apéndices globales para cada apéndice:
def reqBody = mockRequest.getRequestContent() // def reqBodyParams = [:] reqBody.tokenize("&").each // , { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID ( ); { // , , “?:” – : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") // … return "200_OK" } else { return "400_BadRequest" }
Las variables asignadas se pueden ver en la ventana de configuración del servicio:
Por lo tanto, describimos la lógica completa del servicio Mock en este método, y en los apéndices para los métodos API, es suficiente escribir un script que lea el valor de respuesta de la variable global:
Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}"
AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}"
Si necesita agregar scripts de tiempo de espera, respuestas demoradas, agregue la variable de retraso, por ejemplo:
Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing…
Y en la secuencia de comandos agregamos:
… Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}"
Si es necesario respaldar la solicitud repetida, transferimos la lista de respuestas:
Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK
Y en la secuencia de comandos de procesamiento, agregue tokenize y elimine la respuesta ya enviada, si no es la última:
def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) }
Como resultado, obtuvimos un servicio Mock simple, que es fácil de mover entre bancos de pruebas y entornos, porque el archivo del proyecto es un archivo xml. El servicio se inicia inmediatamente después de la importación, sin configuraciones adicionales (a excepción de cambiar la dirección del servidor y el puerto, por supuesto). Por el momento, nos ayuda a probar la aplicación independientemente de la estabilidad del servidor IPA y los posibles períodos de tiempo de su inaccesibilidad.
Lo que planeamos agregar: integre esta solución para probar aplicaciones antes y durante el desarrollo de la API. Por ejemplo, cuando su descripción ya está lista en forma de archivo swagger, pero el servidor está en proceso de configuración. Los ciclos de desarrollo de API y aplicaciones cliente no siempre coinciden. En este punto, es útil probar la aplicación del cliente en desarrollo para algo, y el servicio Mock puede ayudar mucho.
UPD: en caso de que tenga preguntas y comentarios útiles.