Decoupling Mock Tools from Service Architecture: Challenges and Solutions for Microservice Testing

In modern microservice systems, using Mock tools at the service‑level often leads to two major issues: (1) work interference, where enabling a Mock for one application unintentionally redirects dependencies of other applications, and (2) activation latency, caused by the registration center’s caching and propagation delays, which destabilizes automated interface tests.

To address these problems, a four‑part architecture is introduced:

1) Servlet agent (switch) : modifies JVM network proxy variables to transparently redirect outbound requests to a local Mock proxy and provides an API for toggling the Mock on or off.

2) Local Mock proxy (bridge) : forwards requests to either the Mock server or the original target based on a configurable routing table, acting as a bridge between the tested application and its dependencies.

3) Mock server : implements the actual Mock behavior, returning predefined responses; any mock framework with an external configuration API can be used here.

4) Mock configuration client : offers simple APIs for test scripts or GUI tools to control the Mock lifecycle (enable, disable, configure) without modifying application code.

By localizing Mock instances, adding a transparent switch, and inserting a routing bridge, the solution decouples Mock tools from the service architecture, eliminating cross‑application interference and reducing latency, while preserving test reliability and efficiency.

The approach is generic enough to be extended beyond JVM‑based services, potentially moving the switch to the system layer to support applications written in other languages.