Mountebank – Respuestas inject

0
58

Aquí tienes la serie completa de tutoriales sobre Mountebank:

Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2,3 Ghz Intel Core i7, 16GB DDR4).
  • Sistema Operativo: Mac OS Catalina 10.15.5
  • Entorno de desarrollo: JDK 11, IntelliJ, Docker, Postman

 

Introducción

En este artículo vamos a ver el uso del último tipo de respuesta que nos provee Mountebank, las respuestas de tipo inject, con este tipo de respuesta Mountebank nos permite extender sus funcionalidades por defecto, espero que os guste y/o sirva de ayuda en vuestros tests.

Este artículo está dividido en 5 partes:

  • Respuestas de tipo inject
  • Añadir estado
  • Seguridad
  • Cómo depurar en Mountebank
  • Conclusiones

 

Respuestas de tipo inject

De vez en cuando podemos encontrarnos con servicios que utilizan algo distinto a JSON o XML, por ejemplo CSV. CSV sigue siendo un formato relativamente popular en ciertos tipos de integraciones de servicios, especialmente en aquellos que implican la transmisión de información de tipo bulkstyle, como por ejemplo el servicio meteorológico del sitio weather.com.

Si tuvieses un caso de prueba que nos diera los días con un porcentaje de humedad superior al 60%, tendríamos un problema por que Mountebank no soporta CSV de forma nativa, y por lo tanto no tiene un predicado que busque niveles de humedad superiores al 60%, estamos fuera de sus capacidades incorporadas.

Para todos estos casos donde pensamos que Mountebank no nos puede ayudar vamos a crear nuestros propios predicados usando JavaScript y el predicado de inyección, pero primero tenemos que iniciar mountebank con el indicador de línea de comandos –allowInjection:

Todos los predicados que hemos visto hasta ahora funcionan en un solo campo de la petición.  No es así con inject, que nos da control total al pasar todo el objeto de solicitud a una función JavaScript que escribimos. Esa función JavaScript devuelve true si el predicado coincide con la petición y false de otra manera, como se muestra a continuación:

Enchufar la función en la matriz de predicados de un stub implica que se use JSONescaping, que reemplaza las nuevas líneas con ‘n’, y escapa de las comillas dobles:

También podemos crear nuestra propia respuesta en mountebank. En su forma más simple, la función de inyección de respuesta refleja la de los predicados, aceptando toda la petición como parámetro. Es responsable de devolver un objeto de respuesta que mountebank fusionará con la respuesta predeterminada. Piensa en ello como si estuvieras creando una respuesta de tipo is usando una función JavaScript, de la siguiente manera.

Una función de inyección predicada sólo requiere un parámetro (“config”) que tiene los siguientes campos:

  • request, el objeto de petición específico del protocolo
  • state, un objeto inicialmente vacío al que se le puede agregar estado; será pasado en las llamadas subsecuentes para el mismo impostor.
  • logger, se usa para escribir información de depuración en los registros de mountebank

La función de inyección de respuesta incluye esos campos y añade uno más al parámetro (“config”):

  • callback, una función de devolución de llamada para soportar operaciones asíncronas

Una cosa importante y de la que no podemos perder el foco es que la virtualización de servicios es una estrategia de prueba que nos da determinismo al probar un servicio que tiene dependencias de tiempo de ejecución. No es una forma de reimplementar dependencias de tiempo de ejecución en una plataforma diferente. Aunque mountebank proporciona funcionalidad avanzada para hacer que tus stubs sean más inteligentes cuando necesites que lo sean, lo mejor es no necesitar que sean tan inteligentes. Cuanto más tontos puedan ser sus servicios virtuales, más mantenible será tu arquitectura de pruebas.

 

Añadir estado

Mountebank pasa un parámetro de estado a tus funciones de inyección que puedes usar para recordar información a través de múltiples solicitudes. Inicialmente es un objeto vacío, pero puedes añadirle la información que quieras cada vez que se ejecute la función de inyección.

Vamos a verlo con un ejemplo, empezaremos añadiendo el parámetro a la función e inicializándolo con las variables que desea recordar, en posteriores llamadas utilizaremos el parámetro.

 

Seguridad

La inyección de JavaScript está desactivada de forma predeterminada cuando se inicia mountebank, y por una buena razón. Con la inyección habilitada, mountebank se convierte en un potencial motor de ejecución remota accesible a cualquiera en la red. La inyección es una característica enormemente útil, pero hay que utilizarla teniendo en cuenta las implicaciones de seguridad. 

La primera precaución es no ejecutar mb en su cuenta de usuario. Comenzar mountebank con un usuario sin privilegios, idealmente uno sin credenciales de dominio de red. La siguiente capa de seguridad es restringir qué máquinas pueden acceder a la web de mountebank. Para esto tenemos varias opciones la más sencilla es utilizar el indicador –localOnly, que restringe el acceso a los procesos que se ejecutan en la misma máquina. Esta opción es perfecta cuando tus pruebas se ejecutan en la misma máquina que mountebank, y debería ser la opción por defecto la mayor parte del tiempo. Cuando se requiere pruebas remotas (durante pruebas de carga extensivas, por ejemplo), también podemos restringir qué máquinas pueden acceder al servidor web de mountebank con la bandera –ipWhitelist, que captura un conjunto limitado de direcciones IP. En el siguiente ejemplo vamos a ver como configurar unas únicas direcciones IP remotas que permiten el acceso a mountebank son 10.22.57.137 y 10.22.57.138:

 

Cómo depurar en Mountebank

Escribir funciones de inyección tiene la misma complejidad que escribir cualquier código, excepto que es mucho más difícil depurarlas a través de un IDE porque se ejecutan en un proceso remoto aunque siempre podremos utilizar la depuración de impresión. 

Como ya hemos visto mountebank pasa otro parámetro tanto a la inyección predicada como a la de respuesta para hacer la salida un poco más fácil de detectar en los logs, el logger, veamos un ejemplo sencillo de depuración por impresión:

 

Conclusiones

En este artículo hemos repasado qué son y cómo podemos utilizar los tipos de respuesta inject que proporciona Mountebank para crear nuestros propios predicados con una función JavaScript que acepta el objeto de petición y devuelve un booleano que representa si el predicado coincide o no, también cómo crear nuestras propias respuestas con una función JavaScript que acepta el objeto de solicitud y devuelve un objeto que representa la respuesta. Hemos repasado los principales problemas de seguridad que se pueden dar sino somos cautelosos, también hemos visto cómo manejar el estado en nuestras funciones javascript y por último cómo depurar dichas funciones.

Puedes descargar el proyecto completo aquí.

 

Referencias

http://www.mbtest.org/

https://github.com/bbyars/mountebank

https://github.com/bbyars/mountebank-in-action

https://hub.docker.com/r/bbyars/mountebank

http://www.mbtest.org/docs/api/injection

Dejar respuesta

Please enter your comment!
Please enter your name here