Mocking de APIs con WireMock: la habilidad que todo QA debería dominar en 2026 ¿Cuántas veces tu equipo de backend te dijo "todavía no está la API" y tuviste que esperar para poder testear?
Con WireMock eso deja de ser un problema. Te cuento por qué esta herramienta se volvió indispensable en mi día a día como QA.
🎭 Mock vs Stub: la confusión que casi todos tienen Antes de entrar en WireMock, aclaremos algo que se usa como sinónimo pero no lo es: Stub → Es una respuesta fija y predefinida. Le preguntás algo y siempre te devuelve lo mismo, sin lógica ni verificación. Su objetivo es simplemente "reemplazar" una dependencia para que el test pueda correr. Mock → Además de simular la respuesta, verifica el comportamiento: cuántas veces fue llamado, con qué parámetros, en qué orden. Un mock "sabe" si se usó correctamente.
👉 En testing unitario esta diferencia es clave (piensen en Mockito). En testing de APIs con WireMock, en la práctica trabajamos mayormente con stubs (definimos request → response), aunque la herramienta también permite verificar llamadas (verify()), acercándose al concepto de mock. Por eso WireMock se banca ambos mundos: es un stub server que puede comportarse como mock cuando necesitás validar interacciones.
🤔 ¿Qué es Mocking y cuándo se usa en QA? Simular el comportamiento de una API real sin depender de que esté desplegada, estable o disponible. Es oro puro cuando: * El backend todavía no está listo pero necesitás avanzar con la automatización. * Querés testear casos límite (errores 500, timeouts) que son difíciles de reproducir contra un servidor real. * Necesitás tests rápidos, aislados y reproducibles, sin depender de red ni de datos de terceros.
⚙️ Poniendo manos a la obra Con WireMock levantás un servidor standalone (Java) en minutos, definís tus stubs para GET, POST, PUT, DELETE, jugás con headers y query params, y simulás:
Respuestas exitosas:
200 OK,201 CreatedErrores de cliente:
400 Bad Request,401 Unauthorized,404 Not FoundErrores de servidor:
500 Internal Server ErrorCondiciones reales: latencia, timeouts, respuestas corruptas
Lo más potente: podés generar respuestas dinámicas, devolviendo distintos JSON según los datos del request. Esto te permite simular flujos completos, no solo respuestas sueltas.
🧪 De la teoría a la práctica Podés probar tus mocks con Postman, Bruno o simplemente curl. Y cuando ya tenés confianza, el siguiente paso natural es la automatización: integrar WireMock con Karate, gestionarlo con Maven y correrlo en Jenkins dentro de tu pipeline de CI/CD.
💬 ¿Vos ya usás WireMock en tu stack de testing? ¿O trabajan con otra herramienta para mockear APIs (MockServer, Postman Mock Server, JSON Server)? Me interesa conocer qué usan en sus equipos.
Top comments (1)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support