JMock: A Zero‑Configuration Mocking Platform for Backend Service Dependencies

Background: As JD Retail’s business and technical architecture evolve, multiple front‑ends (PC, mobile web, app, WeChat) rely on a large number of backend services (gateway, search, payment, product, advertising, promotion, order, merchant, supply chain, logistics). The rapid growth and frequent organizational changes have led to missing test environments for many middle‑platform services, causing delays in development, testing, and overall demand delivery.

Problems identified include: (1) lack of test environments for many services, preventing local execution; (2) shared pre‑release environment causing long deployment cycles and conflicts; (3) multi‑team dependencies increasing delivery time.

Solution – JMock Platform: Positioned in the architecture to address service‑dependency gaps, provide mock access, and simplify onboarding.

One‑Click Integration

Developers only need to add a Maven dependency; no additional client configuration is required.

<!-- JMock refer: http://test.jmock.jd.com -->
<dependency>
    <groupId>com.jd.m.mocker</groupId>
    <artifactId>mocker-client</artifactId>
    <version>x.x.x-beta.x</version>
</dependency>

Methods that need to be mocked are annotated with @JMock :

@JMock
public String foo(String param) {
    return param;
}

The SDK automatically disables mocking in production environments to avoid performance impact.

Zero Configuration

JMock follows a zero‑configuration principle, reducing learning and usage cost. It covers three areas:

Basic data zero‑config : Application and user information are auto‑discovered by the SDK.

JSF call zero‑config : Mocking is performed in the JSF filter layer via JSF extension points.

Application health monitoring zero‑config : Health data is reported through Spring lifecycle and new applications are auto‑registered.

Intelligent Mock

Network isolation logic automatically disables mocking when the client is not in a development or test network.

Mock switches can be controlled at SDK, mock‑client, and mock‑server levels. For example, disabling JMock globally via a mocker.properties file:

# Disable JMock
mocker.on=false

At the mock‑server level, switches exist per application and per method, allowing fine‑grained control.

Data Source Smart Control

Mock data can be sourced from:

Historical (cached) data.

Automatic generation using templates.

Intelligent selection: try live service first, then cache, then generate.

Backend dependency: force live service call.

Same‑application source: share data across methods.

Priority order: private template > application template > public template > application‑level source.

Automatic Data Generation

JMock parses class structures to create placeholder‑based JSON templates, then fills them with mock values.

Class structure parsing example (output of JavaTypeStructParser.parse ):

{
   "fields": [
     {
       "name": "id",
       "struct": {
         "range": {"max": 9223372036854775807, "min": -9223372036854775808, "type": "RANGE"},
         "structType": "NOR",
         "targetClassName": "java.lang.Long",
         "valueType": "NUM"
       },
       "structType": "FIELD"
     },
     {
       "name": "appName",
       "struct": {"structType": "NOR", "targetClassName": "java.lang.String", "valueType": "STR"},
       "structType": "FIELD"
     }
   ],
   "structType": "OBJ",
   "targetClassName": "com.jd.jone.api.v2.beans.sysapp.AppWithSysInfo"
}

Placeholder generation (via JtspTpl.parse ) produces:

{
  "id": "@natural",
  "appName": "@last",
  "@type": "com.jd.jone.api.v2.beans.sysapp.AppWithSysInfo"
}

Mock data is then generated (via Mockingly.mock ) and returned as JSON:

{
  "id": 36322613,
  "appName": "White",
  "@type": "com.jd.jone.api.v2.beans.sysapp.AppWithSysInfo"
}

Placeholder Specification

Placeholders follow a @placeholder syntax (case‑insensitive) and support numeric, string, boolean, and date types, similar to MockJS. Example:

{
  "name": {
    "first": "@FIRST",
    "middle": "@FIRST",
    "last": "@LAST",
    "full": "@first @middle @last"
  }
}

After filling, the result becomes:

{
  "name": {
    "first": "Charles",
    "middle": "Brenda",
    "last": "Lopez",
    "full": "Charles Brenda Lopez"
  }
}

Service Dependency Analysis

JMock can analyze which interfaces are mocked versus which are live, checking registration in the JSF registry and response time (<1000 ms) to determine service health, helping developers locate dependency issues quickly.

Future Outlook

JMock aims to further reduce development cost and improve efficiency by adding parameterized mocking, full‑link tracing, and integration with test cases, while continuing to enhance data‑source intelligence and dependency analysis.

For inquiries, contact [email protected] .