Full-Link Mocking: Technical Background, Implementation Details, and Open Issues

Mocking has become commonplace throughout the software development and testing lifecycle, especially when code depends heavily on external services; developers often fix expected responses in code to simulate those services.

Many modern applications also rely on caches that store data derived from database queries; during testing, directly modifying cache data provides a quick way to validate scenarios, effectively acting as another form of mock.

To address the need for a convenient and rapid mocking approach for multi‑dependency, frequently changing environments, the authors propose a "full‑link mock" solution that extends traditional mocking across different stages of the call chain.

The technical background highlights that advances in underlying infrastructure (e.g., logging systems, ES tracing) enable complete tracking of application call chains, allowing headers to be propagated transparently and providing seeds for mock generation.

Key components include:

Using Elasticsearch (ES) trace data as a source for mock rules.

Injecting mock behavior via header propagation across the full call chain.

Figures illustrate conventional mock diagrams, ES trace links, and the overall mock‑link architecture.

Implementation considerations focus on three main aspects:

Response speed: Mock services must meet service‑level latency requirements, avoiding timeouts. This involves caching rule lookups, pre‑serializing protobuf payloads, and minimizing extra network hops.

Contract dependency: Service contracts (e.g., protobuf definitions) must be updated before ES trace ingestion; otherwise, missing or outdated contracts cause failures. A centralized contract repository and careful replacement logic are required.

Usability: The system aims to reduce user interaction to a few inputs, such as providing an ES share link, while the platform handles configuration and rule generation automatically.

Practical challenges encountered during deployment include handling duplicate calls with inconsistent results, cache expiration issues that prevent mock activation, and HTTP 302 forwarding scenarios where mock services need to return a 200 status.

Overall, the full‑link mock system is continuously refined to adapt to diverse business needs, with future work focusing on supporting stress‑testing requirements and simplifying rule definitions (favoring header matching over complex regex or XPath expressions).