Design and Implementation of a Unified Mock Service Platform for the SCF Framework
This article introduces the SQC mock service platform built for the SCF microservice framework, outlines three mock implementation approaches, explains why the third solution was chosen, and details the platform’s architecture, features, and benefits for backend testing and integration.
SQC is a service‑level functional and performance testing platform developed by the R&D Management Basic Testing Group, aimed at providing an easy‑to‑use mock mechanism for external services that are unstable or unavailable during functional or performance testing.
The SCF (Service Communication Framework) is a proprietary microservice framework of 58.com that offers service registration, discovery, load balancing, dynamic routing, authentication, rate limiting, monitoring, and alerting, supporting tens of thousands of service instances and billions of daily calls.
Because backend services built on SCF often encounter instability or unmet requirements, developers need mock tools for unit testing, integration testing, and complex business scenario verification, prompting the search for a unified mock solution.
Three representative solutions are discussed:
Solution 1 – Service‑level mock: Generates mock SCF services via bytecode manipulation, providing independent IP/port deployment and multi‑version support. Drawbacks include one‑interface‑per‑mock limitation and high resource consumption.
Solution 2 – Request interception: Intercepts requests and forwards them to a unified mock service, requiring instrumentation of interfaces and potentially affecting framework logic; it also incurs higher integration cost and compatibility challenges.
Solution 3 – Platform‑integrated mock (chosen): Introduces a low‑cost, plug‑and‑play mock capability through a dedicated package, requiring no additional deployment or business‑code changes. It offers easy usage, maintenance, extensibility (e.g., contract verification, protocol mock), applicability across unit, integration, and regression testing, and supports SCF binding/unbinding.
The three solutions are compared in a table (see image). The first two were deemed imperfect due to deployment overhead and framework coupling, leading to the adoption of Solution 3.
Implementation of Solution 3 resulted in the SQC mock service platform. Its architecture (illustrated below) provides several advantages:
1) No business‑code modification; mock is instant‑plug‑in for testing or debugging. 2) No extra instrumentation; configuration is done via the platform. 3) Method‑level mock support, allowing selective mocking of individual methods while other calls reach the real SCF service. 4) Seamless web‑layer and SCF integration, facilitating multi‑layer mock scenarios.
The platform’s key features include:
Tag‑based management: automatic generation of mockKey and binding to scfKey.
Rule matching with default rules and support for multiple return values per method.
Multi‑version support via distinct mockKeys.
Mock rule switch to enable/disable specific mocks.
Multi‑environment capability (office, test, sandbox; not production).
API for creating and managing mock rules, already used by commercial and Anjuke testing teams.
Client‑side filter configuration to turn mock on or off.
Future enhancements planned for the mock platform include fuzzy matching with weighting, data‑recording capabilities through SCF extensions, and more sophisticated rule management.
Author: Hou Huibin, Technical Platform Test Architect, responsible for framework, storage, search, and account testing platforms, with extensive experience in server‑side testing technologies.
58 Tech
Official tech channel of 58, a platform for tech innovation, sharing, and communication.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.