A la hora de desarrollar aplicaciones, enfrentarse a la inestabilidad de los servicios externos puede ser un verdadero dolor de cabeza. Cuando dependemos de una API que a veces cae o que devuelve datos que no controlamos, el proceso de depuración se vuelve lento y frustrante, ya que no siempre podemos forzar los errores que necesitamos probar.
Para solucionar esto, existen herramientas de imitación o mocking que nos permiten levantar un servidor ficticio. Esto significa que podemos interceptar las llamadas de red y devolver exactamente el JSON o el código de estado que queramos, permitiéndonos trabajar de forma aislada y predecible, sin que nos importe si el servidor real está caído o si estamos en un avión sin Wi-Fi.
Dominando MockWebServer en entornos Android y Kotlin
MockWebServer, creado por la gente de Square (los mismos genios detrás de OkHttp y Retrofit), es una librería espectacular para verificar cómo reacciona tu app ante diferentes respuestas HTTP. En lugar de hacer peticiones a internet, la aplicación se comunica con un servidor local que ejecuta todo el stack HTTP, lo que hace que las pruebas sean más realistas que simular dependencias en pruebas unitarias simplemente mockeando una interfaz de Java.
Para ponerlo en marcha con Retrofit, lo ideal es configurar la instancia en el método setup de los tests y cambiar la URL base para que apunte al servidor local (normalmente 127.0.0.1 en el puerto 8080). Si estamos haciendo tests de UI con Espresso, necesitaremos un Test Runner personalizado que le diga a Android que use una versión de la aplicación configurada para el entorno de pruebas, evitando así que la app intente conectar con la API real.
Una de las funciones más útiles es el método enqueue, que nos permite encolar respuestas específicas. Podemos definir si queremos un código 200 para el camino feliz o un 404 o 500 para comprobar que la aplicación no explote y maneje la excepción adecuadamente. Esto es vital para validar que los adaptadores de datos funcionan correctamente, transformando, por ejemplo, fechas en formato String a objetos DateTime sin errores.
Mock Service Worker (MSW): La potencia del interceptor en Web
Si nos movemos al mundo del frontend con JavaScript, TypeScript y frameworks como Vue, React o Angular, Mock Service Worker es la herramienta definitiva. A diferencia de otros mocks, MSW utiliza un Service Worker para interceptar solicitudes a nivel de red, lo que significa que no tienes que cambiar ni una línea de la lógica de tus llamadas API.
Para integrarlo, se suele instalar la librería y ejecutar un comando de inicialización que coloca los archivos necesarios en el directorio público del proyecto. Una práctica muy común es usar variables de entorno (como VITE_APP_MOCKS) para que el sistema de mocks solo se active durante el desarrollo o en el entorno de pruebas, manteniendo el servidor de producción limpio.
Para que los datos no sean siempre los mismos y aburridos, se recomienda integrar @faker-js/faker. Esta librería permite generar nombres, correos y números aleatorios pero realistas, lo que ayuda a detectar errores de maquetación cuando los textos son más largos de lo esperado. Además, MSW permite simular retrasos en la respuesta mediante la función delay, ideal para testear esos molestos estados de carga o spinners.
WireMock y la arquitectura de Microservicios
Cuando trabajamos con microservicios, el caos de dependencias es real. A veces, para probar un solo servicio, necesitarías levantar otros cinco, bases de datos y sistemas de mensajería. Aquí es donde WireMock entra al rescate, ofreciendo un servidor mock extremadamente flexible que puede ejecutarse como una aplicación independiente, embebido en Java o mediante un contenedor de Docker.
WireMock destaca por su capacidad de mapear peticiones complejas basándose en URLs, cabeceras o cookies. Podemos programar respuestas dinámicas usando plantillas JSON o XML y simular escenarios donde una petición depende del estado de la anterior. Un punto fuerte es su modo proxy, que permite grabar respuestas reales de un servidor para luego reproducirlas en el entorno de test.
Sin embargo, hay que tener ojo con un riesgo: el servidor mock puede quedar desactualizado respecto al servicio real. Para evitar que el cliente espere algo que el servidor ya no da, se recomienda complementar esto con pruebas de contrato (Contract Testing) usando herramientas como Pact, asegurando que el acuerdo entre cliente y servidor se mantenga intacto.
Sistemas de Mocking avanzados y utilidades adicionales
Existen también implementaciones basadas en NodeJS que ofrecen servicios REST completos para cursos de frontend, incluyendo autenticación JWT y protección XSRF. Estas herramientas suelen leer datos directamente de ficheros JSON locales, facilitando la creación de recursos personalizados simplemente añadiendo un archivo en la carpeta de datos y registrándolo en la configuración.
Estas soluciones avanzadas permiten probar flujos complejos, como el registro de usuarios con confirmación vía webhooks o la gestión de tokens de refresco siguiendo el estándar OAuth 2.0. Incluso se pueden simular conexiones de WebSocket para chats bidireccionales o flujos de datos en tiempo real, proporcionando una experiencia de desarrollo completa sin necesidad de infraestructura backend real.
Para evitar problemas de seguridad en el navegador, estos servidores suelen venir con cabeceras CORS habilitadas, permitiendo que cualquier dominio de origen pueda realizar peticiones. Además, la implementación de estándares como RFC 7807 para los detalles de los errores HTTP permite que los desarrolladores sepan exactamente qué ha fallado mediante respuestas estructuradas y legibles.
El uso de estas herramientas de simulación permite que los equipos de desarrollo avancen sin bloqueos, transformando las pesadas pruebas de integración en pruebas unitarias rápidas y fiables. Al tener un control total sobre el código de estado, el cuerpo de la respuesta y los tiempos de red, se logra un software mucho más robusto, capaz de soportar cualquier imprevisto que pueda ocurrir en el mundo real.
