El concepto de mocking es uno de esos términos científicos o ingenieros en los que se deforma una acepción de una palabra para generalizar un concepto.
Mock es una expresión inglesa similar a burla en el sentido de engañar. Y hacer mocking en ingeniería es como burlar a un sistema para que crea que ocurre algo que no es real.
Es por tanto un sistema de prueba o test, ya sea unitario o funcional, en el que se genera un elemento que simula un periférico conectado y sus respuestas.
Supongamos un sistema que analiza la temperatura de una habitación y cada cierto tiempo comunica a un servidor externo el incremento. Este servidor respondería con un mensaje en el que se indicarían instrucciones para mantener la temperatura mediante el control de un aire acondicionado con bomba de calor.
Cuando el ingeniero está desarrollando el software del sistema, no contará ni con la sonda de temperatura física, ni con el servidor externo, ni con el equipo de aire acondicionado. Pero debe probar las conexiones, mensajes, protocolos e interfaces con estos antes de integrar el software en un sistema real.
Para ello deberá desarrollar diferentes test que prueben dichas interfaces. Estos pequeños test son los candidatos perfectos para hacer mockings. Pero no todos los test entran en esta categoría.
Una posibilidad sería un sistema que simule variaciones de temperatura de la habitación. Pero este test no sería un mocking propiamente dicho ya que no “interactúa” con el prototipo. Solo transmite información. Sería más bien una colección de casos unitarios con los diferentes tipos de comandos.
Lo mismo ocurriría con el test para controlar el equipo de aire acondicionado si está interfaz controla los mandos directamente de forma eléctrica. En caso de que existiera un protocolo de establecimiento de sesión y mensajería de órdenes con un controlados instalado en el aparato de aire, sí que se podría implementar un mock o hacer mocking.
El candidato más razonable es el servidor externo que decidirá las acciones a realizar para controlar la temperatura.
Supongamos que se establece un procedimiento para iniciar sesión entre nuestro equipo y el servidor. Así como un mensaje de actualización de temperaturas y otros para establecer los controles que deben ser transmitidos al aire acondicionado. Confirmaciones, mantenimientos de sesión, o actualización de datos podrían ser otros de los flujos de comunicación establecidos entre los dos sistemas.
El mock por lo tanto será un sistema que simule un servidor web. Además deberá cumplir el protocolo de inicio de sesión, recibir las temperaturas, enviar órdenes y resolver el resto de flujos de mensajería que se hayan definido. Estas órdenes no hace falta que sean coherentes con la temperatura enviada ni el sistema real. Pueden ser envíos aleatorios de encendido y apagado del dispositivo. De toma de datos o simplemente bucles preestablecidos y con comunicaciones síncrona o asíncronamente.
El mocking en este caso puede implementarse en un lenguaje de programación como Python o JAVA. Estos tienen una buena cantidad de librerías y ejemplos. O utilizar un servicio web programable como puede ser Postman. De esta forma el mock simulará al servidor y engañará al sistema de una forma controlada por el programador, que podrá analizar las respuestas de sus sistema a dicha interacción. Buscando respuestas determinadas a diferentes estímulos.
El sistema diseñado como mocking suplantará al servidor web engañando a nuestro sistema para forzar los comportamientos y comprobar las respuestas.
El desarrollo de sistemas mocking para probar nuestros proyectos parece por tanto un gran método. Pero tiene sus trampas. Por un lado debemos conocer las herramientas con las que diseñarlos. En caso contrario podrían generarse situaciones en las que se cometan errores. Puede ser que el desarrollador de nuestro ejemplo no conozca tan a fondo la programación de servidores. Lo que genere un mal diseño del flujo del programa que suponga falsos positivos o errores.
Cualquier tipo de test, ya sea automático o manual, debe diseñarse, implementarse y ejecutarse con cuidad pues de los resultados depende el proyecto y su fiabilidad. Cuando las pruebas se realizan dentro del propio ámbito del producto, el mismo equipo de desarrollo puede implementarlas. Pero en muchos de los mocks, el sistema que debemos suplantar, será un elemento ajeno al proyecto. Por lo que puede ser necesaria la participación de personal externo.
Otro caso puede ser que para que el servidor web pueda probar la interacción con el sistema. El equipo de desarrollo generará en este caso un mocking que suplante a su propio sistema y que se entregará a terceros para pruebas pre-integración. Este suele ser una parte reducida y modular del producto final con las funcionalidades que se quieran probar.
Otro momento en el que suele emplearse el mocking es en la fase de diseño. Puede ser que los encargados de la elección de herramientas necesiten pequeñas demostraciones de la operatividad o el modo de implementación del proyecto en diferentes lenguajes o herramientas valorados. En este caso pueden generarse pequeños mocks con los que mostrar resultados y a los que aplicar métricas. En el caso del ejemplo, podrían realizarse mocks en Python y JAVA para evaluar el tiempo de implementación y la velocidad en las transmisiones entre los dos lenguajes.
La practica del mocking es diversa y productiva. Pero como toda burla debe analizarse con cuidado. Por razones de diseño o implementación puede no estar exenta de errores y por tanto no se deben tomar como absolutos. Pero es una muy buena toma de contacto y gestión. Ayuda al desarrollo y al test. Así como a tomar decisiones a la hora de atacar diseños. Por lo que puede ser, bien analizado, una gran ayuda para los desarrolladores en la ejecución de proyectos complejos.
